diff --git a/techniques/aria/aria-log-role.html b/techniques/aria/aria-log-role.html deleted file mode 100644 index 07f2c971ba..0000000000 --- a/techniques/aria/aria-log-role.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - aria-log-role: ARIA23: Using role=log to identify sequential information updates - - - - - - - -

ARIA23: Using role=log to identify sequential information updates -

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Content using Accessible Rich Internet Applications (WAI-ARIA). -

-

This technique is not referenced from any Understanding document.

-
-
-

Examples

-
-

Example 1: Updating the contents of a chat conversation

-
- -

Comments that users type into a chat input field are appended to the end of the chat - history region. The region is marked with role of log so that new additions are announced by ATs. When each new chat message appears, a - screen reader should announce its content (depending on AT/browser compatibility). -

- -
-
-	<div id="chatRegion" role="log" aria-labelledby="chatHeading">
-		<h4 id="chatHeading">Chat History</h4>
-		<ul id="conversation">
-			<li>The latest chat message</li>
-		</ul>
-	</div>
-
-

Working example: chatlog.html

-
-
-

Example 2: Updating the log of a server

-

An application log records time-stamped activities. The log is exposed in the app - as a view, with the region marked with the role of log so that the new additions are announced by the ATs. (The default value for the aria-relevant attribute is "additions", so the removal of the old top entries due to log size limitations - will not be announced.) When each new log entry is added, a screen reader announces - it. -

-
-	<div id="activityLog" role="log">
-		<h4 id="logHeading">Recent activity</h4>
-		<ul id="logentries"">
-			<li>08:03 UserX logged off</li>
-		</ul>
-	</div>
-
-

Working example: serverlog.html

-
-
-
- - \ No newline at end of file diff --git a/techniques/css/C41-enhanced.html b/techniques/css/C41-enhanced.html deleted file mode 100644 index 3fc16fa350..0000000000 --- a/techniques/css/C41-enhanced.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - C41-enhanced: Creating a strong focus indicator within the component - - - - - - - - -

Creating a strong focus indicator within the component

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

All technologies that support CSS.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is to create a highly visible focus indicator that - has sufficient contrast against the internal background color of a component. -

-
-
-

Examples

-

The examples demonstrate a simple implementation where a focus styles is applied to - blue background. As the indicator is contained inside the component, you can be sure - it maintains contrast whatever background the component is placed on -

-
-

Example 1: Inner border

-

HTML

<button>Example button</button>

CSS to provide the indicator. It narrows the scope to buttons within the main element. -

button { 
-    background-color: #3f86d4 /* medium blue */
-    color: white;
-    padding: 10px;
-    border: 1px #333 solid;
-}
-main button:focus { 
-    outline: 2px #fff5be solid; /* light yellow */
-    outline-offset: -4px;
-}
- Three blue buttons with a dark border, the middle button showing a bright yellow outline inside the button. - -
Figure 1 The default and focused states of the button.
- -
-
-
-
-

Resources

-

Resources are for information purposes only, no endorsement implied.

- -
- -
-

Tests

-
-

Procedure

-

For each focusable user interface element:

-
    - -
  1. Place keyboard focus on each focusable user interface element on the page using the - keyboard. -
  2. - -
  3. Check that the focus indicator area is at least the size of a 2 CSS px border around - the component. -
  4. - -
  5. Check that the change of contrast of the indicator between focused and unfocused states - has a ratio of 4.5:1 for the minimum focus indicator area. -
  6. - -
-
-
-

Expected Results

-
    - -
  • #2 and #3 are true.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/css/focus-indicator-inner.html b/techniques/css/focus-indicator-inner.html deleted file mode 100644 index 6628100d60..0000000000 --- a/techniques/css/focus-indicator-inner.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - focus-indicator-inner: Creating a focus indicator within the component - - - - - - - -

Creating a focus indicator within the component

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

All technologies that support CSS.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is to create a highly visible focus indicator that - has sufficient contrast against the internal background color of a component. -

-
-
-

Examples

-

The examples demonstrate a simple implementation where a focus styles is applied to - blue background. As the indicator is contained inside the component, you can be sure - it maintains contrast whatever background the component is placed on -

-
-

Example 1: Inner border

-

HTML

<button>Example button</button>

CSS to provide the indicator. It narrows the scope to buttons within the main element. -

button { 
-    background-color: #3f86d4 /* medium blue */
-    color: white;
-    padding: 10px;
-    border: 1px #333 solid;
-}
-main button:focus { 
-    outline: 2px #fff5be solid; /* light yellow */
-    outline-offset: -4px;
-}
- Three blue buttons with a dark border, the middle button showing a bright yellow outline inside the button. - -
Figure 1The default and focused states of the button.
- -
-
-
-
-

Resources

-

Resources are for information purposes only, no endorsement implied.

- -
- -
-

Tests

-
-

Procedure

-

For each focusable user interface element:

-
    - -
  1. Place keyboard focus on each focusable user interface element on the page using the - keyboard. -
  2. - -
  3. Check that the focus indicator area is at least the size of a 2 CSS px line along - the longest edge of the component. -
  4. - -
  5. Check that the change of contrast of the indicator between focused and unfocused states - has a ratio of 3:1 for the minimum focus indicator area. -
  6. - -
  7. If the focus indicator does not have 3:1 contrast ratio with its adjacent colors, - check that it is at least 2px thick. -
  8. - -
-
-
-

Expected Results

-
    - -
  • #2, #3, #4 are true.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/css/reflow-url.html b/techniques/css/reflow-url.html deleted file mode 100644 index 2d7a4f4b61..0000000000 --- a/techniques/css/reflow-url.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - reflow-url: Allowing for Reflow with Long URLs and Strings of Text - - - - - - - -

Allowing for Reflow with Long URLs and Strings of Text

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Content using technologies that support Cascading Style Sheets (CSS). -

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

Long sets of characters without a space, such as URLs shown as content, can break - reflow when the page is zoomed. The objective of this technique is to present URLs - without introducing a horizontal scroll bar at a width equivalent to 320 CSS pixels - or a vertical scroll bar at a height equivalent to 256 CSS pixels. This is done by - using CSS techniques that adapt to the available viewport space. Note: Using a human - readable text link, rather than a long URL, is better for usability and accessibility. -

-

By default most browsers will wrap long URLs at the following characters:

- -

Sometimes these are not enough to ensure that long URLs will not overflow the viewport.

-
-
-

Examples

-
-

Example 1: Example: Breaking long URLs

-

Using the following CSS will cause long URLs to break at appropriate places (hyphens, - spaces, etc.) and within words without causing reflow. -

-

List of CSS declarations used and why they are used:

-
    - -
  • overflow-wrap: break-word: Allows words to be broken and wrapped within words. -
  • - -
  • word-wrap: break-word: Allows words to be broken and wrapped within. (Microsoft only) -
  • - -
    a {overflow-wrap: break-word;}

Note: IE and Edge only support this declaration when used with the * (wildcard) - selector -

    * { word-wrap: break-word;}

Working Example

-
-
-
-

Tests

-
-

Procedure

-

For strings of text that are wider than 320px check:

-
    - -
  1. Display the web page in a user agent capable of 400% zoom and set the viewport dimensions - (in CSS pixels) to 1280 wide and 1024 high. -
  2. - -
  3. Zoom in by 400%.
  4. - -
  5. For content read horizontally, check that all content and functionality is available - without horizontal scrolling. -
  6. - -
  7. For content read vertically, check that all content and functionality is available - without vertical scrolling. -
  8. - -
-
-
Note
-

If the browser is not capable of zooming to 400%, you can reduce the width of the - browser proportionally. For example, at 300% zoom the viewport should be sized to - 960px wide. -

-
-
-
-

Expected Results

-

Checks #3 and #4 are true.

-
-
-
- - \ No newline at end of file diff --git a/techniques/failures/413 Failure.html b/techniques/failures/413 Failure.html deleted file mode 100644 index 5b49d93240..0000000000 --- a/techniques/failures/413 Failure.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - - 413 Failure: Failure of Success Criterion 4.1.3 due to providing status messages that cannot be - programmatically determined through role or properties - - - - - - - - -

Failure of Success Criterion 4.1.3 due to providing status messages that cannot be - programmatically determined through role or properties -

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Technologies that support Accessible Rich Internet Applications (WAI-ARIA). -

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is to describe a failure where status messages are - used in content but are not communicated to the user due to a lack of appropriate - roles or properties. -

-

The initial step in confirming a failure of Status Messages is to check that new dynamic - content meets the definition of a status message. There are two criteria that determine - if changed content on a page represents a status message: - -

    - -
  1. the new content does not take focus (does not change context);
  2. - -
  3. the new content provides information to the user on the outcome of an action, the - state of an application, the progress of a process, or the existence of errors. -
  4. - -
- Where updated content does not conform to the definition of status message, a failure of 4.1.3 has not taken place. -

-

The second step in this failure technique involves examining code. Where dynamic - content meets the definition of a status message, its container can be examined for - an appropriate WAI-ARIA role or property which allows it to be programmatically determinable - as a status message. Currently there are only a small number of techniques available - to indicate status messages to assistive technologies. They are: - -

- The absence of all of these techniques predicts a failure for the status message - be announced to the user. Additionally, if the role or property is not set before the dynamic content is added, this also predicts a failure. -

-

Since additional techniques may exist to alert an assistive technology, the final - step of this failure technique is confirming whether an assistive technology (such - as a screen reader) detects the dynamic content and exposes the information to users. - Where a status message exists but is not surfaced by assistive technology, it is confirmation - that a failure has taken place. -

-
-
-

Examples

-
-

Example 1: Including a search results message without a status role

-

When a user carries out a search by pressing a Search button, the page content is - updated with the results of the search, displayed in a section below the Search button. - Since the search has no results, the change to content conveys the status message - "0 results returned". This text is not given an appropriate role for a status message, - and so a screen reader will not announce "Zero results returned" unless the user repositions - to that text. Since the status message is not automatically presented to the user - (i.e., instead, it must be manually discovered by the individual), it fails 4.1.3. -

-

Working example: search results message without appropriate role

-
-
-
-

Tests

-
-

Procedure

-

For content that is dynamically added to the page:

-
    - -
  1. Check that the element containing the updated content does not take focus
  2. - -
  3. Check that the new content provides information to the user on one of the following:
  4. - -
      - -
    • the success or result of an action
    • - -
    • the waiting state of an application
    • - -
    • the progress of a process
    • - -
    • the existence of errors
    • - -
    - -
  5. Check that the element containing the new content does not have a pre-existing aria - role of status, alert, log, or progressbar, or an aria-live attribute -
  6. - -
  7. Check that the status message is not surfaced (i.e., announced) by assistive technology
  8. - -
-
-
-

Expected Results

-
    - -
  • If #1 through #4 are all true, then content fails the Success Criterion.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/failures/F-dragging.html b/techniques/failures/F-dragging.html deleted file mode 100644 index 2dc4f3990e..0000000000 --- a/techniques/failures/F-dragging.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - F-dragging: Failure of Success Criterion 2.5.X Dragging due to not providing a single pointer - method for the user to operate a function that does not require a dragging movement - - - - - - - - -

Failure of Success Criterion 2.5.X Dragging due to not providing a single pointer - method for the user to operate a function that does not require a dragging movement -

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Content using any technology which supports pointer input.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this failure is to avoid situations in which people with motor impairments - who cannot operate content because the only way to actuate a function is by dragging - a target element from its initial position to some other position. The failure occurs - when there is no alternative single pointer input available to actuate the function. - The alternative may involve a series of single pointer interactions (for example, - activating a target to be moved; opening a dropdown menu; and selecting a drop destination - from the list of menu items offered). -

-
-
-

Examples

-
-

Example 1: List re-ordering

-

A list of items can be re-ordered by picking up an item and dragging it upwards or - downwards. Other elements move dynamically to open a gap where the picked-up target - can be dropped. There is no alternative way to re-order the list that can be executed - via a single pointer input. -

-
-
-

Example 2: Kanban board

-

In a Kanban implementation for process management, tasks can be dragged horizontally - across from one ‘swimming lane’ to another in order to change the status of tasks - (for example, to change the status of a task from “in process” to “completed”). There - is no alternative way to move targets between lanes that can be executed via a single pointer input. -

-
-
-
-

Tests

-
-

Procedure

-
    - -
  1. Check the interface for the presence of functions triggered by dragging movements
  2. - -
  3. Check that there is a single pointer input alternative to operate the same function -
  4. - -
-
-
-

Expected Results

-
    - -
  • If #2 is false, then this failure condition applies and the content fails this Success - Criterion. -
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html b/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html deleted file mode 100644 index 6b8515ad5b..0000000000 --- a/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html +++ /dev/null @@ -1,194 +0,0 @@ - - - - - failure-concurrent-input-mechanisms-touch-or-mouse-keyboard: Failure due to interactions being limited to touch-only on touchscreen devices - - - - - - - -

Failure due to interactions being limited to touch-only on touchscreen devices

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

All technologies that include interactive controls (such as links, form inputs, or - complex custom widgets) and that can detect the presence of different input modalities. -

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this Failure is to describe situations where users on devices that - have a touchscreen are unable to use other input modalities available to them (such - as an additional/external mouse or keyboard). -

-

There are various methods and heuristics for web content to determine if a user's - device has a touchscreen. However, even when a touchscreen is present, other input - modalities may be available to users. It is not necessarily the case that the user - will be interacting with the web content (exclusively, or at all) using the touchscreen. -

-

If, when a touchscreen is detected, web content is designed to be operated exclusively - through touch, these users will be unable to operate the content using their other - (possibly preferred) input mechanisms. -

-
-
-

Examples

-
-

Example 1: Only using touch-specific JavaScript event listeners when a touchscreen - is detected -

-

These types of approaches have historically been popular for "mobile" specific development, - to ensure that touchscreen interactions are more responsive and immediate (due to - the way that touch interactions used to add a delay of approximately 300ms between - a "tap" interaction and the generic click event being fired). -


-/* inferring the presence of a touchscreen based on
-   support for the Touch Events API */
-
-if (window.TouchEvent || ('ontouchstart' in window)) {
-  /* set up event listeners for touch */
-  target.addEventListener('touchend', ...);
-  ...
-} else {
-  /* set up event listeners for mouse/keyboard */
-  target.addEventListener('click', ...);
-  ...
-}
-				

-/* inferring the presence of a touchscreen based on
-   the CSS Media Queries 4 Interaction Media Features
-   match for a "coarse" primary input mechanism */
-
-if (window.matchMedia && window.matchMedia("(pointer:coarse)").matches) {
-  /* set up event listeners for touch */
-  target.addEventListener('touchend', ...);
-  ...
-} else {
-  /* set up event listeners for mouse/keyboard */
-  target.addEventListener('click', ...);
-  ...
-}
-				

Similarly, web content that omits relevant/necessary keyboard event listeners (e.g. - for the correct keyboard interaction with a complex widget, such as a tab interface) - when a touchscreen is detected - under the assumption that on a touch device, keyboard - support won't be necessary. -


-/* inferring the presence of a touchscreen based on
-   the navigator.maxTouchPoints property defined in
-   the Pointer Events API */
-
-if (window.PointerEvent && ('maxTouchPoints' in navigator) &&
-    (navigator.maxTouchPoints > 0)) {
-	/* no need to listen to keyboard - there's a touchscreen... */
-	...
-} else {
-	/* set up event listeners for keyboard interactions */
-  target.addEventListener('keyup', ...);
-  ...
-}
-				
-
Note
-

Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard - but only in situations - where a touchscreen interface was also detected. -

-
-
-
-

Example 2: Hiding/omitting controls for mouse and keyboard users when a touchscreen - is detected -

-

Web content containing interactive widgets such as content carousels, with visible - buttons to operate the widget (such as previous/next buttons, or a visible scrollbar/slider). - These visible controls are hidden/omitted when a touchscreen is detected, under the - assumption that users will simply use touch gestures to operate the widgets, and no - other alternatives are then provided for keyboard or mouse users. -


-/* using CSS Media Queries 4 Interaction Media Features
-   to hide particular elements in the page (such as a container
-   with visible controls) when a "coarse" primary input is present */
-
-@media (pointer: coarse) {
-  #widget .controls { display: none; }
-}
-				

Depending on the specific implementation, authors may allow mouse interactions with - widgets that mirror touch gestures - for instance, allowing mouse users to also drag/swipe - carousels, rather than just relying on clickable previous/next controls or scrollbars. - In these cases, hiding controls when a touchscreen is detected will still allow users - to operate the widget with the mouse (unless this interaction has also been suppressed/omitted - when the touchscreen was detected, as per the previous example). However, if the only - keyboard-operable controls for the widget were hidden, and no alternative for keyboard - users was provided (such as allowing cursor key operation), this situation would still - fail Success Criterion 2.5.6. -

-
-
Note
-

Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard and (depending on the touch gesture that the user is expected to perform) Success Criterion - 2.5.1 Pointer Gestures. -

-
-
-
-
-

Tests

-
-

Procedure

-
    - -
  1. Open the content on a device with a touchscreen and at least one additional input - modality - this includes touch-enabled laptops and touchscreen devices (smartphones - or tablets) with a paired external keyboard and mouse. -
  2. - -
  3. Check that all interactive controls can be operated using not only the touchscreen, - but also the additional input mechanisms (keyboard and mouse) -
  4. - -
  5. If the presence of the touchscreen caused interactive controls not to be displayed - (compared to the same content when viewed on a device without a touchscreen), check - that there are alternative controls/ways for users of other additional input mechanisms - to operate the content -
  6. - -
-
-
-

Expected Results

-
    - -
  • If checks #2 or #3 are false, the content fails the Success Criterion.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/general/G-Dragging.html b/techniques/general/G-Dragging.html deleted file mode 100644 index 8237aec4c9..0000000000 --- a/techniques/general/G-Dragging.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - G-Dragging: Ensuring that a single pointer operable alternative is available for dragging movements - that operate on content - - - - - - - - -

Ensuring that a single pointer operable alternative is available for dragging movements that operate on content -

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Content using any technology which supports pointer input.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this Technique is to ensure that people with motor impairments who - cannot carry out dragging movements are presented with a single pointer operable alternative. Some direct manipulation - interfaces allow users to pick up targets and move them to another position, for example, - to change the position of an item in a priority list in a list, or to change the status - of a task in a Kanban implementation (a type of visual process management view which - shows tasks in vertical lanes representing process steps such as ‘scheduled’, ‘processed’, - ‘completed’). -

-

The single pointer operable alternative may require the user to carry out a series - of single pointer interactions (for example, activating a target to be moved; opening - a dropdown menu; and selecting a drop destination from the list of menu items offered). -

-
-
-

Examples

-
-

Example 1

-
    - -
  • A list of items can be re-ordered by picking up an item and dragging it upwards or - downwards. Other elements move dynamically to open a gap where the picked-up target - can be dropped. After a single pointer activation, the list items display up and down - arrows which allow a step-wise re-ordering of the the list via a single pointer inputs (taps or clicks at the up or down arrow). -
  • - -
  • A vertical priority list indicates the priority of items listed. Each item can be - ‘picked up’ with a pointer and dragged up or down to another position. The other list - items rearrange dynamically. To the left of each list item, a number in a text field - shows the current priority position. For any of the items, users can put in another - number. This leads to a dynamic reordering and renumbering of the priority list. -
  • - -
  • In a Kanban implementation for process management, tasks can be dragged horizontally - from one ‘swimming lane’ to another in order to change the status of tasks (for example, - to change the status of a task from “in process” to “completed”). One or several items - in a lande can be selected by a single tap or click. A single pointer activation of - a drop-down menu labelled “Move selected items to” offers a selection of drop targets - (other lanes). A further single pointer activation over the desired menu item moves - targets to the specified lane. -
  • - -
  • In a Kanban implementation for process management, tasks can be dragged horizontally - from one ‘swimming lane’ to another in order to change the status of tasks. A directional - horizontal swipe over an item moves it to the adjacent lane. This process can be repeated - until the item is in the desired lane. -
  • - -
-
-
- -
-

Tests

-
-

Procedure

-

For interface elements that support dragging:

-
    - -
  1. Check the interface for the presence of functions triggered by dragging movements. -
  2. - -
  3. Check that there is a single pointer input alternative to operate the same function -
  4. - -
-
-
-

Expected Results

-
    - -
  • Check #2 is true.
  • - -

    If this is a sufficient technique for a success criterion, failing this test procedure - does not necessarily mean that the success criterion has not been satisfied in some - other way, only that this technique has not been successfully implemented and cannot - be used to claim conformance. -

    - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/general/G222.html b/techniques/general/G222.html deleted file mode 100644 index b2d782cdc6..0000000000 --- a/techniques/general/G222.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - G222: Provide persistently visible controls - - - - - - - - -

Provide persistently visible controls

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.2 success criteria. The Applicability section explains the scope of the technique, - and the presence of techniques for a specific technology does not imply that the technology - can be used in all situations to create content that meets WCAG 2.2. -

-
-
-
-

Applicability

-

Content implemented in any technology.

-

This technique relates to Success Criterion 3.2.7: Visible Controls (Sufficient). -

-
-
-

Description

-

The objective of this technique is to ensure that controls are visible without requiring - the user hover with the mouse or another pointer device or move the keyboard focus - to the control. This is important when the user needs the control to progress or - complete a process. Ensuring users can see the controls they need prevents users from - having to search for controls and remember where they are located. This improves success - for individuals with cognitive and learning disabilities and memory impairments. -

-

To meet this technique use controls that are visible without onmouseover or onfocus - events. -

-

Some pages may appear cluttered when the same control is repeated in multiple places - on the page. Often in these cases, the control is not needed to progress but is functioning - as a shortcut through the process. If the control is provided in a later step when - it is needed to progress, then these shortcuts do not need to be displayed. -

-
-
-

Tests

-
-

Procedure

-

For controls that progress or complete a process:

-
    - -
  1. Verify that the controls are visible at the time they are needed without requiring - pointer hover or keyboard focus. -
  2. - -
-

Note: Where a page has multiple page variations (i.e., in a responsive design) controls - should be tested in each variation. -

-
-
-

Expected Results

-
    - -
  • #1 is true.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/general/Gxxx-highly-visible-focus-indicator.html b/techniques/general/Gxxx-highly-visible-focus-indicator.html deleted file mode 100644 index bcf2239732..0000000000 --- a/techniques/general/Gxxx-highly-visible-focus-indicator.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - Gxxx-highly-visible-focus-indicator: Using an author-supplied, highly visible focus indicator - - - - - - - - -

Using an author-supplied, highly visible focus indicator

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.2 success criteria. The Applicability section explains the scope of the technique, - and the presence of techniques for a specific technology does not imply that the technology - can be used in all situations to create content that meets WCAG 2.2. -

-
-
-
-

Applicability

-

Generally applicable.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is enhance the focus indicator in the browser, by - creating a highly visible one in the content. This technique is very similar to G195: Using an author-supplied, visible focus indicator, but with a stronger indicator to meet Focus Appearance (Enhanced). -

-
-
-

Examples

- -
-

Example 2: Form Elements

-

A Web page includes a form inside a table. The borders of both the table and the form - elements are thin, black lines. When focus lands on a form element, the element is - outlined with a 5 pixel red line that is partially transparent. The red is equivalent - to a hex color of #CA0000, providing a 6:1 contrast ratio with the white background. -

-
-
-

Example 3: Menus

-

A Web page includes an interactive menu with sub-menus. A user can move focus in the - menu using the arrow keys. As focus moves, the currently focused menu item changes - its background to a different color, which has a 15:1 contrast ratio with the surrounding - items (whilst maintaining text contrast). -

-
-
- -
-

Tests

-
-

Procedure

- -

For each user interface component on the page that should receive keyboard focus:

- -
    - -
  1. Navigate to the component and check that it has a visible focus indicator that is - not obscured by other content. -
  2. - -
  3. Check that the focus indicator area is at least double the size of a 1 CSS px border - around the component. -
  4. - -
  5. Check that the change of contrast of the indicator between focused and unfocused states - has a ratio of 4.5:1 or more for the minimum focus indicator area. -
  6. - -
- -
-
-

Expected Results

- -
    - -
  • Checks #2, #4, and #5 are true.
  • - -
- -
-
-
- - \ No newline at end of file diff --git a/techniques/general/hidden-control-1.html b/techniques/general/hidden-control-1.html deleted file mode 100644 index 3cd961d9cc..0000000000 --- a/techniques/general/hidden-control-1.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - - hidden-control-1: Provide persistently visible controls - - - - - - - - -

Provide persistently visible controls

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.1 success criteria. The Applicability section - explains the scope of the technique, and the presence of techniques for a specific - technology does not imply that the technology can be used in all situations to create - content that meets WCAG 2.1. -

-
-
-
-

Applicability

-

Content implemented in any technology.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is to ensure that controls are visible without requiring - the user hover with the mouse or another pointer device or move the keyboard focus - to the control. This is important when the user needs the control to progress or - complete a process. Ensuring users can see the controls they need prevents users from - having to search for controls and remember where they are located. This improves success - for individuals with cognitive and learning disabilities and memory impairments. -

-

To meet this technique use controls that are visible without onmouseover or onfocus - events. -

-

Some pages may appear cluttered when the same control is repeated in multiple places - on the page. Often in these cases, the control is not needed to progress but is functioning - as a shortcut through the process. If the control is provided in a later step when - it is needed to progress, then these shortcuts do not need to be displayed. -

-
-
-

Tests

-
-

Procedure

-

For controls that progress or complete a process:

-
    - -
  1. Verify that the controls are visible at the time they are needed without requiring - pointer hover or keyboard focus. -
  2. - -
-

Note: Where a page has multiple page variations (i.e., in a responsive design) controls - should be tested in each variation. -

-
-
-

Expected Results

-
    - -
  • #1 is true.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/techniques/general/hidden-control-2.html b/techniques/general/hidden-control-2.html deleted file mode 100644 index e258cac74a..0000000000 --- a/techniques/general/hidden-control-2.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - - hidden-control-2: Provide a setting to make controls visibly persist - - - - - - - - -

Provide a setting to make controls visibly persist

-
-

Important Information about Techniques

-

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how - they relate to the normative WCAG 2.2 success criteria. The Applicability section explains the scope of the technique, - and the presence of techniques for a specific technology does not imply that the technology - can be used in all situations to create content that meets WCAG 2.2. -

-
-
-
-

Applicability

-

Content implemented in any technology.

-

This technique is not referenced from any Understanding document.

-
-
-

Description

-

The objective of this technique is to ensure that controls are visible without requiring - the user hover with the mouse or another pointer device or move the keyboard focus - to the control. This is important when the user needs the control to progress or - complete a process. Ensuring users can see the controls they need prevents users from - having to search for controls and remember where they are located. This improves success - for individuals with cognitive and learning disabilities and memory impairments. -

-

To meet this technique, provide a setting that makes controls needed to progress or - complete a process visible without onmouseover or onfocus events. -

-

Some pages may appear cluttered when the same control is repeated in multiple places - on the page. In these cases, it may make sense for the controls to only appear on - hover by default. Provide a setting that changes the default to display the controls - without pointer hover or keyboard focus. If setting information can be retained by - the system, maintain this setting across sessions. -

-
-
-

Tests

-
-

Procedure

-

For controls that progress or complete a process:

-
    - -
  1. Identify controls that only display when pointer hover or mouse focus is over them.
  2. - -
  3. Locate a setting that changes these controls so that they visibly persist.
  4. - -
  5. Test that all controls needed to progress or complete a process remain visible.
  6. - -
-

Note: Where a page has multiple page variations (i.e., in a responsive design) controls - should be tested in each variation. -

-
-
-

Expected Results

-
    - -
  • #3 is true.
  • - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/accessible-authentication-no-exception.html b/understanding/accessible-authentication-no-exception.html deleted file mode 100644 index 3dcd1de90d..0000000000 --- a/understanding/accessible-authentication-no-exception.html +++ /dev/null @@ -1,227 +0,0 @@ - - - - - Understanding Success Criterion 3.3.8: Accessible Authentication (No Exception) - - - - - - - - -

Understanding Success Criterion 3.3.8: Accessible Authentication (No Exception)

-
-

Success Criterion 3.3.8 Accessible Authentication (No Exception) (Level AAA): A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step - in an authentication process unless that step provides at least one of the following: -

-
- -
Alternative
- -
Another authentication method that does not rely on a cognitive function test.
- -
Mechanism
- -
A mechanism is available to assist the user in completing the cognitive function test.
- -
-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, - and secure method to log in, access content, and undertake tasks. This criterion is - the same as Accessible Authentication but without the exceptions for objects and user-provided content. -

-

The scenarios where the two exceptions might apply are authentication mechanisms which:

- -
-
-

Benefits

-

The benefits of this success criterion are the same as Accessible Authentication. -

-

People with cognitive issues relating to memory, reading (for example, dyslexia), - numbers (for example, dyscalculia), or perception-processing limitations will be able - to authenticate irrespective of the level of their cognitive abilities. -

-
-
-

Examples

-

The examples of this success criterion are very similar to the Accessible Authentication. -

- -
-
-

Related Resources

-

Resources are for information purposes only, no endorsement implied.

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G218: Email link authentication - -
  2. - -
  3. - Providing a properly marked up email and password inputs (Potential future technique) - -
  4. - -
  5. - Providing WebAuthn as an alternative to username/password (Potential future technique) - -
  6. - -
  7. - Providing a 3rd party login using oAuth (Potential future technique) - -
  8. - -
  9. - Using two techniques to provide 2 factor authentication (Potential future technique) - -
  10. - -
-
-
-
-

Key Terms

-
cognitive function test
-
- - - - - -

A task that requires the user to remember, manipulate, or transcribe information. - Examples include, but are not limited to: -

- -
    - -
  • memorization, such as remembering a username, password, set of characters, images, - or patterns. The common identifiers name, e-mail, and phone number are not considered - cognitive function tests as they are personal to the user and consistent across websites; -
  • - -
  • transcription, such as typing in characters;
  • - -
  • use of correct spelling;
  • - -
  • performance of calculations;
  • - -
  • solving of puzzles.
  • - -
- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/dragging.html b/understanding/dragging.html deleted file mode 100644 index ba78acc323..0000000000 --- a/understanding/dragging.html +++ /dev/null @@ -1,189 +0,0 @@ - - - - - Understanding Success Criterion 2.5.7: Dragging - - - - - - - - -

Understanding Success Criterion 2.5.7: Dragging

-
-

Success Criterion 2.5.7 Dragging (Level AA): All functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging - is essential. -

-

This requirement applies to web content that interprets pointer actions (i.e. this - does not apply to actions that are required to operate the user agent or assistive - technology). -

-

Is there an assistive technology that helps for people with mobility impairments? - The group would like feedback on the frontier between AT & author responsibility. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The intent of this Success Criterion is to ensure functionality that uses a dragging - movement (e.g. sliders, drag-and-drop interfaces) has another single pointer mode of operation without the need for the dexterity required to drag elements. -

-

Some people cannot perform dragging motions in a precise manner. Others use a specialized - or adapted input device such as a head pointer, eye-gaze system, or speech-controlled - mouse emulator, which makes dragging cumbersome, error-prone, or outright impossible. -

-

When an interface implements functionality that uses dragging motions, some users - can tap or click, but not accurately maintain contact whilst performing a dragging - motion. An alternative method must be provided so that users with mobility impairments - that use a pointer (mouse, pen, or touch contact) can use the functionality. -

-

2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard - accessible, however, it is possible to create an interface that works with dragging - and keyboard controls that does not work using only clicks or taps. -

-

A dragging movement is a pointer interaction where only the endpoints matter. Once - the pointer engages with a target, the target (or a position mark related to the target) - will follow the pointer regardless of the direction of the pointer movement. The target's - movement may be constrained to one axis and often, to a particular range on that axis, - but within those constraints, the x or y position of the target will mirror the corresponding - x or y position of the pointer until the pointer disengages the target. -

-

In contrast to dragging movements, path-based gestures involve at least an initial - directionality of the pointer movement. This is defined by stating that the path has - to go through at least one intermediate point to qualify as pointer gesture. The intermediate - point defines the gesture as requiring a specific path, even if the complete path - is not defined. For more details, refer to Understanding Success Criterion 2.5.1 Pointer Gestures. -

-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G219: Ensuring that a single pointer operable alternative is available for dragging movements - that operate on content - -
  2. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

- -
-
-
-

Key Terms

-
dragging movement
-
- - - - -

an operation where the pointer engages with an element on the down event and the element - (or a representation of its position) follows the pointer -

- -
-
Note
-

The element could be, for example, a list item, a text element, or an image.

-
- -
-
-
essential
-
- - - -

if removed, would fundamentally change the information or functionality of the content, - and information and functionality cannot be achieved in another way that would conform - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/findable-help.html b/understanding/findable-help.html deleted file mode 100644 index 6bc19ad913..0000000000 --- a/understanding/findable-help.html +++ /dev/null @@ -1,469 +0,0 @@ - - - - - Understanding Success Criterion 3.2.6: Findable Help - - - - - - - - -

Understanding Success Criterion 3.2.6: Findable Help

-
-

Success Criterion 3.2.6 Findable Help (Level A): For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to - at least one way of finding help is included in the same relative order on each page: -

- -

Access to help mechanisms may be provided directly on the page, or may be provided - via a direct link to a different page containing the information" -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The intent of this success criterion is to ensure users can find help for completing - tasks on a Web site. This is distinct from interface-level help, such as contextual - help, features like spell checkers, and instructional text in a form. -

-

Locating the help mechanism in a consistent location across pages makes it easier - for users to find it. For example, when a mechanism or link is located in the header - of a Web page, it will be presented in the header of all pages within the set of Web - pages. -

-

The location in a smaller viewport may be different than in a larger viewport but - the mechanism or link will remain in the same location throughout the size. The location - should remain consistent both visually and programmatically. -

-

While it would be best for all sites to offer this type of help, the requirement is - for: -

- -

and is actively supported.

-

A single page Web application (compared to a Web page) shows multiple "pages" or views of content at the same URI. If a web application - uses different URIs for each view of the content, that is considered multiple Web pages because the URI changes. -

-

When having problems completing a task on a Web site, people with some types of disabilities - may not be able to work through the issue without further help. Issues could include - difficulty: - completing a form, or finding a document or page which provides information required - to complete a task. -

-

Without help, some users may abandon the task. They may also fail to correctly complete - a task, or they may require assistance from people who do not necessarily keep private - information secure. -

-

Self help methods beyond the site, such as using internet search to find the contact - information for an organization, can be too difficult. Further, the user’s disability - may make it more difficult to find the help available (such as a “contact us” link, - phone number, or support page) if the information is not present within a few interactions - (e.g., displayed in the header, or via a menu). In addition, for some users with disabilities, - struggling to complete a task on a site may cause additional cognitive challenges - when searching for help within the site. -

-

When a user is quickly able to find help, they are able to complete the task even - if they encounter challenges. -

-

At least one of the following mechanisms to get help should be included:

- -

The human contact details should enable the user to connect with the organization - or the part of the organization that can assist with the content. For example, an - online jobs / recruitment portal should provide a contact method for the team that - supports the recruitment portal and not a catch-all for the entire company. Each layer - of contact added prolongs the time before the user will receive help. -

-

The human contact mechanism enables a person to express what they are looking for - using their own words. For some with cognitive disabilities, this may be the best - way for them to find an answer to their problem. -

-

For pages for which no human support is available, a self-help option should say that - no human support is available. Self-help options should go beyond allowing the user - to search within the site. Contextual help is still recommended (See SC 3.3.5 for - more information) but a self-help option should provide a single location that makes - it easier for people with cognitive disabilities to understand what help is available - without having to hunt for it. While some people may easily be able to identify that - no support would be available for a particular type of Web site, this may not be apparent - to some users with disabilities. -

-

If a chatbot is provided, it should meet other WCAG success criteria for your conformance - level. Chatbots which work more effectively for everyone, and particularly for people - with cognitive disabilities should: -

- -

It is not the intent of this Success Criterion to require authors to provide help - information on PDFs or other static documents that may be available for viewing/download - from the Web pages. It is also not the intent to require contact information if: -

- -

It is also not the intent of this Success Criterion to require a human be available - at all times. If the human contact is not available during certain hours or certain - days, information should be provided so the user can tell when it will be available. - -

-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. G220: Provide a contact-us link
  2. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

-
    - -
  • Inconsistent Help Location - -
  • - -
-
-
-
-

Key Terms

-
assistive technology
-
- - - -

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements - of users with disabilities that go beyond those offered by mainstream user agents - -

- - -
-
Note
-

functionality provided by assistive technology includes alternative presentations - (e.g., as synthesized speech or magnified content), alternative input methods (e.g., - voice), additional navigation or orientation mechanisms, and content transformations - (e.g., to make tables more accessible). - -

-
- - -
-
Note
-

Assistive technologies often communicate data and messages with mainstream user agents - by using and monitoring APIs. - -

-
- - -
-
Note
-

The distinction between mainstream user agents and assistive technologies is not absolute. - Many mainstream user agents provide some features to assist individuals with disabilities. - The basic difference is that mainstream user agents target broad and diverse audiences - that usually include people with and without disabilities. Assistive technologies - target narrowly defined populations of users with specific disabilities. The assistance - provided by an assistive technology is more specific and appropriate to the needs - of its target users. The mainstream user agent may provide important functionality - to assistive technologies like retrieving Web content from program objects or parsing - markup into identifiable bundles. - -

-
- - -

Assistive technologies that are important in the context of this document include - the following: - -

- - -
    - - -
  • screen magnifiers, and other visual reading assistants, which are used by people with - visual, perceptual and physical print disabilities to change text font, size, spacing, - color, synchronization with speech, etc. in order to improve the visual readability - of rendered text and images; - -
  • - - -
  • screen readers, which are used by people who are blind to read textual information - through synthesized speech or braille; - -
  • - - -
  • text-to-speech software, which is used by some people with cognitive, language, and - learning disabilities to convert text into synthetic speech; - -
  • - - -
  • speech recognition software, which may be used by people who have some physical disabilities;
  • - - -
  • alternative keyboards, which are used by people with certain physical disabilities - to simulate the keyboard (including alternate keyboards that use head pointers, single - switches, sip/puff and other special input devices.); - -
  • - - -
  • alternative pointing devices, which are used by people with certain physical disabilities - to simulate mouse pointing and button activations. - -
  • - - -
- - -
-
-
set of web pages
-
- - - -

collection of web pages that share a common purpose and that are created by the same author, group or organization - -

- - -

Examples include a publication which is split across multiple Web pages, where each - page contains - one chapter or other significant section of the work. The publication is logically - a single contiguous unit, and contains navigation features that enable access to the - full set of pages. - -

- - -
-
Note
-

Different language versions would be considered different sets of Web pages.

-
- - -
-
-
single page web application
-
- - - -

Pages obtained from a single URI that provide navigation which changes the meaning - of the Web page -

- -
-
-
user agent
-
- - - -

any software that retrieves and presents Web content for users

- - -

Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving, rendering, and interacting with Web content. - -

- - -
-
-
web page
-
- - - -

a non-embedded resource obtained from a single URI using HTTP plus any other resources - that are used in the rendering or intended to be rendered together with it by a user agent - -

- - -
-
Note
-

Although any "other resources" would be rendered together with the primary resource, - they would not necessarily be rendered simultaneously with each other. - -

-
- - -
-
Note
-

For the purposes of conformance with these guidelines, a resource must be "non-embedded" - within the scope of conformance to be considered a Web page. - -

-
- - -

A Web resource including all embedded images and media.

- - -

A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program - lives entirely at http://example.com/mail, but includes an inbox, a contacts area - and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar - to display, but do not change the URI of the page as a whole. - -

- - -

A customizable portal site, where users can choose content to display from a set of - different content modules. - -

- - -

When you enter "http://shopping.example.com/" in your browser, you enter a movie-like - interactive shopping environment where you visually move around in a store dragging - products off of the shelves around you and into a visual shopping cart in front of - you. Clicking on a product causes it to be demonstrated with a specification sheet - floating alongside. This might be a single-page Web site or just one page within a - Web site. - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/fixed-reference-points.html b/understanding/fixed-reference-points.html deleted file mode 100644 index d631a7c971..0000000000 --- a/understanding/fixed-reference-points.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - Understanding Success Criterion 2.4.13: Fixed Reference Points - - - - - - - - -

Understanding Success Criterion 2.4.13: Fixed Reference Points

-
-

Success Criterion 2.4.13 Fixed Reference Points (Level A): For web content with page break locators, a mechanism is available to navigate to each locator. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this success criterion is to allow people using assistive technology - to find references to content based on the page break locators found in the default view or printed version of a publication. -

-

Page numbering has long been a fundamental way to identify and communicate the location - of written content. Page numbers are used constantly in references, footnotes, endnotes, - and bibliographies. Particularly, they are critical in academic and learning environments. -

-

Digital publishing has provided valuable access to content for people who are blind, - have low vision, dyslexia or other cognitive disabilities. In order to consume the - information the content may be adapted to use a different layout, or presented to - them using assistive technology. If there is no clear way to find a specific page - from the print version that was referenced by a professor in class, because the electronic - version is zoomed-in and that paragraph is on page 145 of the user's version of the - content, the user misses out on valuable and sometimes critical information to understanding - the reference. -

-

In publishing, there can be many different editions of a work, e.g. a second edition - or a paperback edition. There is a requirement (separate from accessibility) for metadata - in digital publications like EPUB to identify the edition of the title of which this - digital version represents. The page break locaters would be aligned with the specified - edition. -

-
-
Note
-

Statically paginated formats (e.g., PDF) where the user agents include a mechanism - to navigate by page typically meet this success criteria by default. The user agents - for the EPUB format also typically provide the navigation mechanism if a page list - is included. Web browsers do not have a standard page navigation mechanism, so for - HTML content with page break locators it is the author responsibility to add that - mechanism. -

-
-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Related Resources

-

Resources are for information purposes only, no endorsement implied.

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - H99: Provide page list navigation - -
  2. - -
-
-
-
-

Key Terms

-
page break locators
-
- - - - -

programmatic markers that are arranged in a meaningful sequence to determine the location - of a page in relation to others in the set. -

- -

Examples would be:

- -
    - -
  • A digital version of an ebook that has a print version, it includes the page break - locators to align with the print edition. -
  • - -
  • A digital book is published with no print equivalent and page break locators are inserted - which supports direct navigation across platforms and form factors. -
  • - -
- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/focus-appearance-enhanced.html b/understanding/focus-appearance-enhanced.html deleted file mode 100644 index b796d86d40..0000000000 --- a/understanding/focus-appearance-enhanced.html +++ /dev/null @@ -1,280 +0,0 @@ - - - - - Understanding Success Criterion 2.4.13: Focus Appearance (Enhanced) - - - - - - - - -

Understanding Success Criterion 2.4.13: Focus Appearance (Enhanced)

-
-

Success Criterion 2.4.13 Focus Appearance (Enhanced) (Level AAA): When user interface components have keyboard focus, all of the following are true: -

- -
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this Success Criterion is to ensure a keyboard focus indicator is highly - visible. This criterion is closely related to Success Criterion 2.4.11 Focus Appearance (Minimum) and defines a higher level of visibility for the focus indicator. -

-

In relation to Focus Visible (enhanced) this criterion:

- -

The other aspects of the Success Criterion are the same as Focus Visible (Minimum).

-
-
-

Benefits

-

The benefits of this Success Criterion are similar to Focus Appearance (Minimum).

- -
-
-

Examples

-

The examples of this Success Criterion are similar to Focus Appearance (Minimum).

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G223: Using an author-supplied, highly visible focus indicator - -
  2. - -
  3. - C40: Creating a two-color focus indicator to ensure sufficient contrast with all components - -
  4. - -
  5. - C41: Creating a strong focus indicator within the component - -
  6. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

- -
-
-
-

Key Terms

-
css pixel
-
- - - -

visual angle of about 0.0213 degrees

- - -

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. - This unit is density-independent, and distinct from actual hardware pixels present - in a display. User agents and operating systems should ensure that a CSS pixel is - set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[!css3-values]], which takes into account the physical dimensions of the display - and the assumed viewing distance (factors that cannot be determined by content authors). - -

- - -
-
-
focus indicator
-
- - - -

the pixels that are changed to visually indicate when a user interface component is - in a focused state. - -

- - -
-
-
minimum bounding box
-
- - - -

the smallest enclosing rectangle aligned to the horizontal axis within which all the - points of a shape lie. Where a component consists of disconnected parts, such as a - link that wraps onto multiple lines, each part is considered to have its own bounding - box. -

- -
-
-
perimeter
-
- - - -

continuous line forming the boundary of a shape not including shared pixels, or the - minimum bounding box, whichever is shortest. For example, the perimeter calculation for a rectangle is - 2h+2w -4, where h is the height and w is the width and the corners are not counted twice. The perimeter of a circle is - 2𝜋r. -

- -
-
-
user interface component
-
- - - -

a part of the content that is perceived by users as a single control for a distinct - function - -

- - -
-
Note
-

Multiple user interface components may be implemented as a single programmatic element. - "Components" here is not tied to programming techniques, but rather to what the user - perceives as separate controls. - -

-
- - -
-
Note
-

User interface components include form elements and links as well as components generated - by scripts. - -

-
- - -
-
Note
-

What is meant by "component" or "user interface component" here is also sometimes - called "user interface element". - -

-
- - -

An applet has a "control" that can be used to move through content by line or page - or random access. Since each of these would need to have a name and be settable independently, - they would each be a "user interface component." - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/focus-appearance-minimum.html b/understanding/focus-appearance-minimum.html deleted file mode 100644 index df83c8e71d..0000000000 --- a/understanding/focus-appearance-minimum.html +++ /dev/null @@ -1,1232 +0,0 @@ - - - - - Understanding Success Criterion 2.4.11: Focus Appearance (Minimum) - - - - - - - - -

Understanding Success Criterion 2.4.11: Focus Appearance (Minimum)

-
-

Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA): When a user interface component has keyboard focus, the focus indicator: -

- -

Exceptions:

- -

Where a user interface component has active sub-components, if a sub-component receives - a focus indicator, these requirements can be applied to the sub-component instead. -

-

Note: Examples of sub-components that may receive a focus indicator are menu items - in an opened drop-down menu. However, it may also be possible to indicate user interaction - for such sub-components by relying strictly on a visual indication of which item is - selected. Where selectable sub-components have no differentiated focus indicator, the visual - indicator for sub-component selection is measured against 1.4.11 Non-text Contrast requirements, not against this Criterion. -

-

Note: Contrast calculations can be based on colors defined within the technology (such - as HTML, CSS and SVG). Pixels modified by user agent resolution enhancements and anti-aliasing - can be ignored. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this Success Criterion (SC) is to ensure a keyboard focus indicator - is clearly visible and discernible. Focus Appearance (Minimum) is closely related - to 2.4.7 Focus Visible and 1.4.11 Non-text Contrast. Where Focus Visible merely requires a visible focus indicator, this SC defines a - minimum level of visibility. Where Non-text Contrast requires a component to have - adequate contrast against the background in each of its states, this SC requires sufficient - contrast for the focus indicator itself. -

-

For sighted people with mobility impairments who use a keyboard or keyboard-like device - (such as a switch or voice input), knowing the current point of focus is very important. - Visible focus must also meet the needs of users with low vision, who may also be keyboard-only - users. -

-

A keyboard focus indicator can take different forms. This Success Criterion lists - three primary considerations that can be met to consistently achieve a sufficient - focus appearance. It then provides a list of exceptions for a focus indicator which - may be less optimal for some users but still achieves a minimum level of focus appearance. - This Understanding document will elaborate on each of the three primary considerations, - then address the exceptions. -

-
- - -

Encloses

- -

The first of the primary bullets states that the focus indicator "encloses" the user - interface component. This is defined to mean "solidly bounds or surrounds." Both bounds and surrounds describe optimal and established ways of showing focus. Bounds and its related term "bounding box" generally describe a rectangle drawn around the - outside of a user interface component. It is the most common form of focus indication - and is sometimes referred to as a "focus rectangle." -

- - -
- 2 blue buttons with a dark 1 pixel thick offset focus rectangle around the second - -
Figure 1 Passes: A solid focus rectangle around the second of two buttons.
- -
- - -

"Surrounds" also refers to something that solidly encloses a shape. However, a shape - can be surrounded in many ways. For instance, the focus indicator may follow the outline - of the object being enclosed. The difference between bounds and surrounds is illustrated in the following two images of a set of ratings stars. In both examples, - the same three stars have already been selected, and focus is on the third star. -

- -
- 3 of 5 stars are selected with a solid-line rectangular focus indicator around the third - -
Figure 2 Passes: a solidly bound focus rectangle encloses the third of five stars.
- -
- - -
- Three of 5 stars are selected with a solid-line focus indicator in the shape of a star outlining the third - -
Figure 3 Passes: a solid outline indicator surrounds the third of five stars.
- -
- - -

Solidly

- -

Where the indicator does not "solidly" bound or surround the component, as with a - dashed or dotted line, it cannot meet this primary consideration. However, a non-solid - line can still pass if it meets the wording of the exceptions (discussed in more detail - under Exceptions). -

- - -
- 3 of 5 stars are selected with the whole third star outlined with a 1 pixel thick dashed line - -
Figure 4 Fails: the dashed outline does not "solidly bound" the third star and does not meet - the exception language. -
- -
- - -
- 3 of 5 stars are selected with the whole third star outlined with a 2 pixel thick dashed line - -
Figure 5 Passes: the dashed outline does not "solidly bound" the third star; however, the - dashed line meets the area requirements of the exception language. -
- -
- -
-
- - -

Indicator contrasts between its focused and unfocused states

- - -

The second of the primary bullets states that the indicator "has a contrast ratio - of at least 3:1 between its pixels in the focused and unfocused states." The following - illustration shows a minimally contrasting focus indicator, where some of the white pixels making up the page background - have been altered to a mid-grey, which contrast 3:1 with the original white. Authors - are encouraged to exceed the minimum focus appearance. For instance, the dark blue - lines in the first two illustrations are much more visible. -

- - -
- Two orange-yellow five-pointed stars, one with a mid-gray focus rectangle - -
Figure 6 Passes: Two buttons in the shape of a star, with the second surrounded by a focus - indicator whose pixels contrast 3:1 between focused (light grey) and unfocused (white) - states. -
- -
- -
-
- -

Contrasts at least 3:1 against adjacent colors

- - The third of the primary bullets states that the focus indicator must contrast against - the pixels on either side. Where the indicator is offset from the shape and does not - directly abut the component or any other object -- as in all preceding examples -- - it simply needs to contrast at least 3:1 against the page background. Offsetting is - the recommended way of creating a more visible focus indicator. However, where authors - choose to position the indicator so it is directly next to or overlaps another shape, - it must contrast 3:1 against this adjacent shape as well. - - -
- Two orange-yellow five-pointed stars, the second with a tightly cropped blue focus outline - -
Figure 7 Passes: The second of two stars has a star-shaped blue outline that directly abuts - the star, with which it contrasts 3:1, creating a minimally visible focus indicator. -
- -
- -
-
- -

Component keyboard focus

- -

The preamble to this SC is "When a user interface component has keyboard focus..." - The keyboard focus is the point of interaction for someone using a keyboard. For environments with a - keyboard-operable interface, the keyboard focus can be moved around the interface - in order to interact with different components. Whichever component is being interacted - with has focus. -

- - -

WCAG defines user interface component as "a part of the content that is perceived by users as a single control for a distinct - function." Because different users may perceive controls differently, there is a potential - for some variation when interpreting what constitutes both a single control and a distinct function. This is particularly the case when something visually presents in a way that may - differ from how it is programmatically created under the covers. Where there is not - a native HTML component upon which to base designs, there can be great variations - in how the components and their focus indicators are portrayed. Further, some components - have sub-components that can take focus, such as the menu items on a menu. -

- -

Nonetheless, consistent results from different testers were obtained for this SC - by using the focus indicator itself as the gauge of what constitutes the component - being interacted with. For complex components, the three typical focus indicators - are as follows: -

- - -
    - -
  • Focus indicator around only the whole component
  • - -
  • Focus indicators around both the component and subcomponent
  • - -
  • Focus indicator around only the subcomponent
  • - -
- - -

Each of these will be discussed, using a tablist as a familiar complex component.

- - -

Focus indicator around only the whole component

- -
- Three tab buttons shown with a dark blue rectangle around all three tab buttons. - -
Figure 8 A tablist with a focus indicator around only the whole.
- -
- - -

When the focus indicator is shown only around the whole tablist, the user is guided - to considering the tablist as a single user component. The tab items within it are - visually distinguished between selected and unselected states (and visual indicators - of selection state must meet the criteria given in 1.4.11 Non-text Contrast). -

- - -

Having a focus indicator only around the whole is possible where there is no need to have a selected sub-component - while another sub-component has focus. For a tablist which synchronizes its tab panel - content with whatever tab is active, only one tab item can be selected at a time, - and since whatever tab is selected is considered active, a separate focus indicator - is redundant. -

- - -

Result: the group focus indicator must meet the requirements of this SC.

- - -

A radio button group and a star-rating widget, which each use only a whole-component focus indicator, provide working examples - of different complex components that pass the primary requirements of this SC. In - the star ratings example, users can increment the rating by 1/2 stars. Not only is - a focus indicator for each 1/2 star unnecessary, but it would actually be difficult - to achieve without making the interaction confusing. -

- - -

Focus indicators around both the component and subcomponent

- - -
- Three tab buttons shown with a dark blue rectangle around all three tab buttons, the first tab button also has a dark outline as well as a blue bar indicating it is selected. -
- The same tab list showing except the first tab is selected, but the second has the focus outline. - -
Figure 9 The same tablist in two states. In the first, focus is around both the tablist and - the currently selected tab; in the second, focus is around both the tablist and an - unselected tab. -
- -
- - -

For a tablist which does not keep its tab panel content synchronized with whatever - tab is selected, there needs to be a focus indicator for the tab item subcomponent. - This is because the tab item with focus may be different than the selected item. -

- -

The user can navigate to the tablist, which in this implementation has a focus rectangle - around the whole tablist as well as one around a tab item (conventionally the item - that is currently selected). The focus around the whole is helpful in cueing a keyboard - user that this is a complex component that has its own interaction. The user can then - move focus between the unselected and selected tab items -- each of which in turn - has its own focus indicator -- before activating one, which then makes it selected - as well as focused, and updates the tab panel to match. -

- -

In this scenario, either the group focus indicator or the sub-component indicator - must meet the requirements of this Success Criterion. To avoid being overly prescriptive, - the Success Criterion allows authors to choose which makes the most sense. Generally, - if a sub-component focus is necessary, it should be assessed instead of the group - indicator. -

- - -

Result: the focus indicator for the tab item meets the requirements of this SC. The - tablist focus indicator does not need to meet the requirements. -

- - -

A slider to pick colors provides a working example of a different complex component that predominantly shows - focus for the subcomponent. In this case, the thumb slider sub-component has a focus - indicator of sufficient size and contrast to pass the exception. There is also a subtle - focus around the whole slider component, but it does not need to be assessed to pass - this SC. -

- - -

Focus indicator around only the subcomponent

- - -
- Three tab buttons shown and the first button has a dark outline. - -
Figure 10 The same tabs as in the prior set, but the focus indicator around the whole is removed.
- -
- - - -

The same unsynchronized tablist can also be implemented as something which only shows - focus on the tab items and not on the whole. The behaviour is the same as in the prior - example, but there is never a focus indicator placed around the tablist. This interaction - is acceptable, but it is not best practice since it demands more understanding from - the user with less information. For example, some visual cues for the tablist and - tab items (and tab panel) may not be clear. As well, keyboard users may not initially - understand the expected keyboard interaction. -

- - -

Result: the focus indicator for the tab item must meet the requirements of this SC, - judging focus with both selected and unselected tab items. -

- - -

A functional example of sub-component-only tab focus has an indicator that is large enough (at least four times the shortest side) with - sufficient contrast to pass the exception language of this SC. -

- - -

Where something with focus is not a user interface component

- -

Some pages contain very large editing regions, such as web implementations of word - processors and code editors. Unlike a textarea element, which is a user interface component, these large editing regions do not - typically meet the definition of user interface components; they are not "perceived by users as a single control for a distinct function." Providing - focus indicators around such editing regions may still be beneficial to some; however, - where the region is not perceived as a single control, it is not covered by this Success - Criterion. The web page will still need to provide a insertion point (caret indicator) - in such editing regions in order to meet the requirements of 2.4.7 Focus Visible. -

- - -

Some non-operable elements can take focus (such as a heading element that is the target - of a skip link). However, the preamble of this SC refers to user interface components; - it is only when the element with focus is operable by keyboard that this Success Criterion - applies. -

- -
-
- -

Exceptions

- -

In addition to achieving a minimum keyboard focus appearance using the three primary - means described above, an author can also meet this SC's requirements through one - of several exceptions, where either: -

- -
    - -
  • the focus indicator cannot be adjusted by the author,
  • - -
  • the author has not modified the effects of the user agent default, or
  • - -
  • the author provides an indicator of sufficient size and contrast.
  • - -
- -
-
- -

First exception: the focus indicator cannot be adjusted by the author

- - -
-

The focus indicator is determined by the user agent and cannot be adjusted by the - author -

-
- -

Some components or technologies may not allow the author to adjust the focus indicator. - This is the case with HTML select elements (both single and multi-select), where the visual treatments for selection - and focus cannot be adjusted by the author. In this case the Success Criterion does - not apply. -

- -
- A country select element with Afghanistan selected and Albani with focus - -
Figure 11 Passes: The user agent's default select element presentation cannot be modified by the author, so it passes regardless of - the quality of the focus indicator -
- -
- - -
-
- -

Second exception: the default indicator and background are not modified

- -
-

The focus indicator and the indicator’s background color are not modified by the author

-
- -

If the focus indicator and the background behind the focus indicator are not modified - by the author, the Success Criterion does not apply. -

- -

The intent of this exception is to reduce burden on authors by allowing them to rely - on the default indicators provided by user agents (browsers). If all user agents provided - good focus indicators, author would be able to concentrate efforts on other accessibility - considerations. Unfortunately, browser default focus indicators vary by component, - browser, and across devices and operating systems, and the default focus indicators - in some browsers can be difficult to see (such as a 1px dotted outline). For this - reason, most authors override browser defaults in order to overcome these deficiencies - and create a more uniform user experience, regardless of browser. -

- -

Some browser makers are improving their default focus indicators to make them more - visible. As more browsers adopt defaults that meet the primary bullets of this SC, - authors will be able to achieve improved focus indicators without customization. -

- - -

Modifying the focus indicator background

- -

Browser default focus indicators can be made more difficult to see if the author modifies the page background color, for instance using - a blue background in combination with a browser's blue default indicator. -

- - -

[Future image set: a button with a default light blue focus indicator; the same buton - and focus indicator on a light blue page background] -

- - -

As well, if the browser provides an indicator within a component by default, then - authors can potentially reduce the visibility by changing the component color. For - example, if the default indicator on a button is a bright yellow inner focus rectangle, - the authors can negatively affect the focus appearance by making the button yellow - or orange. For this reason, this user agent exception can only be met if the author - both does not modify the default focus indicator and does not modify its background. -

- - - -

[Future image set: a button with a default internal focus indicator; the same button, - now with a colour similar to the default internal focus indicator] -

- -
-
- -

Third exception: an area of the focus indicator meets size and contrast measurements

- -

The last exception allows for focus indicators in different forms if they meet the - size and contrast requirements set out in a series of sub-bullets. -

- - -
- -

Minimum area

- - -
- -
    - -
  • At least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, - or is at least as large as a 4 CSS pixel thick line along the shortest side of a minimum - bounding box of the unfocused component -
  • - -
- -
- - -

The first of these sub-bullets defines a minimum area for the focus indicator using - a calculation for perimeter, and a secondary minimum based on the shortest side of - the control. It does not restrict where the indicators are placed, it is just providing - two methods to calculate a minimum area. -

- - -

For the first calculation, the minimum area of the focus indicator must be at least - as large as the area of a 1 CSS pixel thick perimeter (border) of the control in its - unfocused state. The indicator does not have to be a border, but the indicator's area - must be at least as large. For example, if a control is a rectangle of 90px wide and - 30px tall, the size of the outer border is 90 + 90 + 30 + 30 = 240 CSS pixels. You - then must subtract the 4 corner pixels (which are counted twice, both horizontally - and vertically), for a total minimum area of 236 CSS pixels. -

- - -
-
Note
-

A CSS pixel is what developers use in CSS declarations like “width: 200px”. It is device-independent - and not to be confused with device pixels which vary depending on the physical pixel - density.
- The rest of this document notates CSS pixels as "px". - -

-
- - -

The following 3 examples use a 90px wide by 30px tall button, therefore the surface - area requirement is 236px (240px minus corner 4 pixels). The middle button is focused - in each example. -

- - -
- Three dark blue buttons on a white background. The middle button has a yellow inner border. - -
Figure 12 Passes: the inner outline is slightly smaller than the outer edge of the component - (236px minus 2px on each side), but using a 2px thick indicator means it is well over - the minimum requirement of 236px squared. -
- -
- - -
- Three dark blue buttons on a white background. The middle button has a thick yellow line under the text. - -
Figure 13 Passes: the thick (3px) yellow underline, at 80px almost as long as the longest edge, - multiplied by 3px exceeds the requirement of 236px squared. -
- -
- - -

If controls change size across different variations of a page (e.g., in a responsive - design), it helps to use a proportionally sized indicator such as an outline or background - change. In that way you can be sure of meeting the size requirement. -

- - -

Another way of achieving the area exception is to alter the appearance of the entire - component, for instance by changing its color. This can be effective in a set of closely - placed buttons. The following example using the same set of 5 ratings stars given - in the first illustrations in this document, shows how this can be achieved. However, - it is much more difficult to detect such a focus indicator when components are not - near each other and so cannot be easily compared. For users using magnfication, even - components relatively close together may be difficult to compare, so it is not considered - a best practice. -

- -
- 3 of 5 stars are selected with the whole third star altered in color to indicate focus - -
Figure 14 Passes: a color change applies to the whole third star to indicate focus.
- -
- - -

The Success Criterion includes an alternative size measure of "at least as large as - a 4 CSS pixels border along the shortest side". This is included to allow for smaller - but thick indicators. For example, some controls might be of a fixed height but variable - width, in which case this measure allows for a more consistent approach. -

- - -
- Two dark blue buttons on a white background. The left button has a very thick yellow block of color left of the text. - -
Figure 15 Passes: the yellow block on the left is along the short side, but very thick.
- -
- - -

Typical focus indicators:

- -
    - -
  • A solid outline around the whole component would pass the size requirement;
  • - -
  • A 1 CSS pixel dotted outline around the whole component would not pass the size requirement, as it is roughly 50% of the surface area of a solid line. -
  • - -
  • Changing the background within a control would pass the size requirement;
  • - -
  • A 1px wide vertical line (such as a blinking cursor) would not pass the size requirement; a text input would need a larger or separate focus indicator. -
  • - -
- -

The bigger the visible change when an item receives focus, the easier it is for someone - to see. Authors are encouraged to make the change as significant as possible, for - example by designing a thick border around the element. If you need to use complex - mathematics to work out if a focus indicator is large enough, it is probably a sign - that you should use a larger and proportional indicator that will provide a more visible - indicator. -

- - -

Unusual shapes

- - -

If you have an unusual shape (not rectangular), some mathematics may be required if - the focus indicator is on the edge of the size requirement. For example, if the focusable - control is a circle with a diameter of 100px, the circumference would be 314 pixels. - A 1px (or greater) outline would meet the size criterion. -

- - -
- Two orange circular buttons with an icon in the middle. The right hand circle has a dark outline around the whole circle to indicate focus - -
Figure 16 Passes: a circular button in the default state, and then with a focus indicator.
- -
- - -

If a focus indicator is an irregular shape, such as a drop shadow under a star icon, - it helps if the contrasting area is quite large. -

- - -
- Two yellow star symbols, the second has a dark drop-shadow. - -
Figure 17 Passes? An unfocused star component beside one using a drop shadow to show focus.
- -
- - -

What is the contrasting area of the drop shadow? The quick method is:

- -
    - -
  • Look at the size of the component, how long is it around the edges?
  • - -
  • Look at the (contrasting) area of the focus indicator.
  • - -
  • Mentally compare the focus indicator to the border of the component.
  • - -
- - -

If it is too close to call, you could extract the contrasting area of the focus indicator - and evaluate the surface area. -

- -

Gradients

- -

If a focus indicator has a gradient, the principle is to measure the contrast of the - changed area, and ignore the change that does not meet 3:1. -

- -
- Three buttons, the middle with a heavy drop-shadow indicating focus. - -
Figure 18 Passes? When a gradient is used on a focus indicator, the measure of surface area - should only include the area that has changed enough to meet the 3:1 contrast ratio. -
- -
- -

If you take some spot-checks on the gradient area and establish what area meets the - contrast, it is straightforward to work out if that area is sufficient. -

- -
- The middle button with the drop-shadow included, but the subtle grey areas removed to only show the contrasting area. - -
Figure 19 Passes: the focused button with the non-contrasting areas removed, showing that it - is a thick indicator that meets the requirements. -
- -
- -
-
Note
-

Some of the examples in this document, especially in the Exceptions section, are screen-captured - images of elements. Due to loss of resolution in these images, the actual pixel color - may not match the original. As such, they are intended to be used for illustrative - purposes, and should not be inspected on a pixel-by-pixel basis for sufficient contrast. -

-
- -

Some designs have pages with a non-solid background image covering the whole (or part) - of the page or make use of parallax scrolling effects which result in a near-infinite - number of color combinations if a page is scrolled and/or changes are made to the - viewport size. -

- -

If the contrast of background colors that change are close enough to need to be tested - for each combination then they would likely not meet the user need of people with - low vision in certain scroll combinations and would likely fail in certain combinations - as well. In these cases it would be an easy solution to use a double ring focus indicator or some other mechanism to indicate focus such as a solid box with a border to guarantee - there is sufficient contrast across variations of background images or background - gradients. -

- -

Inline links

- -

If an inline link is broken over multiple lines, some methods of focus indicator are - treated differently by browsers. Using CSS, an outline wraps each part of a wrapped link separately. A border will wrap the whole link as one perimeter. Each part of the link will pass or fail - as though they were separate links. If a 1px CSS border is used rather than outline, - the thickness may need to be increased to compensate for the missing sides as it is - not a complete perimeter for each part of the link. -

- - - - - - -
- - -
- -

Change of contrast

- - -
- -
    - -
  • has a contrast ratio of at least 3:1 against the same pixels in the unfocused state
  • - -
- -
- - -

The second of these exception sub-bullets matches the second of the primary considerations - about a visual difference between a component with and without focus. The greater - the change of contrast between states, the easier it is for users to see it. Authors - are encouraged to make the change of color contrast as great as possible. -

- - -

When a component changes to include a focus indicator, that change can be measured - as a change of color contrast. For example, if a yellow outline is added to a button - on a blue background, the change of color is from blue to yellow. This change can - be measured whether the focus indicator is on the background around the component, - or the background within the component. -

- - -
- Three dark blue buttons on a white background. The middle button has a yellow inner border. - -
Figure 22 Passes: adding a yellow outline to a link is a change of color from blue to yellow. - That change has a contrast ratio of 12:1. -
- -
- - - -

Text and non-text contrast measures use adjacent colors; this Success Criterion measures - the change in color between non-focused and focused states. -

- - -
- Three buttons with light background and dark border on a white background. The middle button has a light grey outline. - -
Figure 23 Fails: the second link has a light-grey (#ccc) focus outline which fails this Success Criterion because the change from white-background to light-grey outline - does not meet 3:1. -
- -
- -
-
Note
-

Color contrast measurements in WCAG are based on luminance (brightness) regardless - of the hue. -

-
- - -

If a control receiving focus changes its background (fill color) to a color that contrasts - less than 3:1 with the original background, that would not pass the change of contrast. -

- - -
- Three black buttons with a dark background. The middle button has a dark grey background. - -
Figure 24 Fails: the second link has a dark-grey (#555) which fails this Success Criterion because the change from black-background to dark-grey background - does not meet 3:1. -
- -
- -

If the background change is sufficient, it is a method of passing the criterion.

- -
- Three black buttons with a dark border and two have a dark background. The middle button has a white background. - -
Figure 25 Passes: the second link has a white background (#fff) which passes this Success Criterion because the change from black-background to white-background - meets 3:1. -
- -
- - -

It is possible to use visual patterns such as strips switching places to disguise - a change of focus indicator. This is not considered a visible indicator. -

- -
- -
- -

Adjacent contrast

- - -
- -
    - -
  • Has a contrast ratio of at least 3:1 against the component, or is no thinner than - 2 CSS pixels. -
  • - -
- -
- - -

The third of these exception sub-bullets is similar to the third primary consideration - -- the focus indicator must contrast with whatever it is next to or it must be thick enough that it is easier to see. Where a control is a solid color, - and you add a border or outline of a very similar color, it is difficult to perceive - the change to the control. -

- - -
- Three dark buttons, the middle one appears very slightly larger due to a thin dark outline. - -
Figure 26 Fails: adding a 1px dark outline around a dark button does not differentiate it. - This example fails the Success Criterion. -
- -
- - -

The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent - colors of the component, or to be separated from the component, or to be at least - 2px thick. -

- - -
- Three dark buttons, the middle one appears larger due to a thick dark outline. - -
Figure 27 Passes: adding a 2px border around the button helps to differentiate which one is - focused. -
- -
- - -
- Three dark buttons, the middle one has a outline slightly offset away from the component, so there is a gap between the component's background and the outline. - -
Figure 28 Adding an outline that is separated from the button helps to differentiate which - one is focused. -
- -
- - -

If the focus indicator uses several colors, any color which does not contrast 3:1 - against adjacent colors can be ignored as long as there is a 2 CSS pixel-thick part - of the focus indicator whose pixels all change at least 3:1 between their focused - and non-focused states. Practically, this means 3D drop-shadows and other stylings - on a focus indicator can likely be ignored. -

- - -
- Two dark blue buttons on a white background. The second one has a dark outline, then a light grey outline on the outside. - -
Figure 29 Passes: the 3px thick dark outline also meets the size and change of contrast requirements. - The light grey outline can be ignored. -
- -
- -

Where a focus indicator is defined in code as a certain size (e.g. 2px thickness) - or color, anti-aliasing can be ignored for the purposes of calculation. Dotted or - dashed outlines have various levels of gaps depending on the browser, screen density, - and thickness. For example, in most browsers a "dotted" line will have roughly half - the number of pixels due to gaps. However, in some sizes or browsers it might be slightly - less than half, so increasing the thickness may be required. -

- -
- - -
- -

Relationship to Non-text Contrast

- -

In combination with 2.4.7 Focus Visible, 1.4.11 Non-text Contrast requires that the visual focus indicator for a component must have sufficient contrast - against the adjacent colors when the component is focused, except where the appearance - of the component is determined by the user agent and not modified by the author. -

- - -

However, Non-text Contrast differs in what it assesses. Unlike the current Success - Criterion, it does not require that the focus indicator has a change of contrast between the focused and non-focused states. Additionally, there is no size requirement and - no exception for user agent default indicators. -

- - -
- Three dark blue buttons, the center button also has a thin dark line around it. - -
Figure 30 A 1px dark outline around a dark button would pass 1.4.11 Non-text Contrast, but - fails this Success Criterion. -
- - -
- - -
- -
-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Related Resources

-

Resources are for information purposes only, no endorsement implied.

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G195: Using an author-supplied, visible focus indicator - -
  2. - -
  3. - C40: Creating a two-color focus indicator to ensure sufficient contrast with all components - -
  4. - -
  5. - C41: Creating a strong focus indicator within the component - -
  6. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

-
    - -
  1. - Using a CSS border for inline text which can wrap (Potential future technique) - -
  2. - -
-
-
-
-

Key Terms

-
css pixel
-
- - - -

visual angle of about 0.0213 degrees

- - -

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. - This unit is density-independent, and distinct from actual hardware pixels present - in a display. User agents and operating systems should ensure that a CSS pixel is - set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[!css3-values]], which takes into account the physical dimensions of the display - and the assumed viewing distance (factors that cannot be determined by content authors). - -

- - -
-
-
encloses
-
- - - - -

Solidly bounds or surrounds

- - -
-
-
focus indicator
-
- - - -

the pixels that are changed to visually indicate when a user interface component is - in a focused state. - -

- - -
-
-
minimum bounding box
-
- - - -

the smallest enclosing rectangle aligned to the horizontal axis within which all the - points of a shape lie. Where a component consists of disconnected parts, such as a - link that wraps onto multiple lines, each part is considered to have its own bounding - box. -

- -
-
-
perimeter
-
- - - -

continuous line forming the boundary of a shape not including shared pixels, or the - minimum bounding box, whichever is shortest. For example, the perimeter calculation for a rectangle is - 2h+2w -4, where h is the height and w is the width and the corners are not counted twice. The perimeter of a circle is - 2𝜋r. -

- -
-
-
user interface component
-
- - - -

a part of the content that is perceived by users as a single control for a distinct - function - -

- - -
-
Note
-

Multiple user interface components may be implemented as a single programmatic element. - "Components" here is not tied to programming techniques, but rather to what the user - perceives as separate controls. - -

-
- - -
-
Note
-

User interface components include form elements and links as well as components generated - by scripts. - -

-
- - -
-
Note
-

What is meant by "component" or "user interface component" here is also sometimes - called "user interface element". - -

-
- - -

An applet has a "control" that can be used to move through content by line or page - or random access. Since each of these would need to have a name and be settable independently, - they would each be a "user interface component." - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/focus-not-obscured.html b/understanding/focus-not-obscured.html deleted file mode 100644 index 9cbf3994e4..0000000000 --- a/understanding/focus-not-obscured.html +++ /dev/null @@ -1,172 +0,0 @@ - - - - - Understanding Success Criterion 2.4.12: Focus Not obscured - - - - - - - - -

Understanding Success Criterion 2.4.12: Focus Not obscured

-
-

Success Criterion 2.4.12 Focus Not obscured (Level AA): When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created - content. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

For sighted people with mobility impairments who use a keyboard-like device (e.g., - a switch, voice input), knowing the current point of focus is very important. When - progressing through a page other content can hide the focused element. -

-

Where other content can overlap with a focused item, the focused element should not - be hidden. Typical types of content that can overlap focused items are sticky footers, - sticky headers, or non-modal dialogues. As a user tabs through the page, these layers - of content can obscure the focused item, including the focus indicator. If the interface - is configurable so that the user can move toolbars and non-modal dialogs around, then - only the initial positions of user-movable content would be considered for testing - and conformance of this success criterion. -

-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - CSS: Using scroll-padding to ensure a sticky header does not obscure the focused item - (Potential future technique). - -
  2. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

-
    - -
  1. - - -
  2. - -
-
-
-
-

Key Terms

-
user interface component
-
- - - -

a part of the content that is perceived by users as a single control for a distinct - function - -

- - -
-
Note
-

Multiple user interface components may be implemented as a single programmatic element. - "Components" here is not tied to programming techniques, but rather to what the user - perceives as separate controls. - -

-
- - -
-
Note
-

User interface components include form elements and links as well as components generated - by scripts. - -

-
- - -
-
Note
-

What is meant by "component" or "user interface component" here is also sometimes - called "user interface element". - -

-
- - -

An applet has a "control" that can be used to move through content by line or page - or random access. Since each of these would need to have a name and be settable independently, - they would each be a "user interface component." - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/focus-visible-enhanced.html b/understanding/focus-visible-enhanced.html deleted file mode 100644 index 5f9b003072..0000000000 --- a/understanding/focus-visible-enhanced.html +++ /dev/null @@ -1,643 +0,0 @@ - - - - - Understanding Success Criterion 2.4.11: Focus Visible (Enhanced) - - - - - - - -

Understanding Success Criterion 2.4.11: Focus Visible (Enhanced)

-
-

Success Criterion 2.4.11 Focus Visible (Enhanced) (Level AA): When a User Interface Component displays a visible keyboard focus, all of the following are true: -

- -

A focus indicator that is larger than the minimum area may have parts that do not - meet the 3:1 contrast ratio, as long as an area equal to the minimum does meet the - contrast ratio. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this success criterion is to ensure a keyboard focus indicator is clearly - visible. This criterion is closely related to SC 2.4.7 focus visible and defines a minimum level of visibility. -

-

For sighted people with mobility impairments who use a keyboard-like device (e.g. - a switch, voice input), knowing the current point of focus is very important. Visible - focus must also meet the needs of low-vision users, who may also be keyboard-only - users. -

-

A keyboard focus indicator can take different forms, this success criterion sets a - requirement to make it is clearly distinguishable. -

-
- -

Keyboard focus

- -

The keyboard focus is the point of interaction for someone using a keyboard. For environments - with a keyboard operable interface, the keyboard focus can be moved around the interface - in order to interact with different elements. Whichever element is being interacted - with has focus. -

- - -

In web pages some components may receive focus as a user presses the tab key to move - to that component and then use the arrow keys to select an option (e.g. tabs, menu - items). The item considered to be focused is whichever is being interacted with. For - example, if you tab to a menu and arrow-down to a menu item, it is the menu item that - is in focus as pressing enter would activate the menu item. -

- - -

Some elements can take focus (such as the target of a skip link), however, it is only - when the element is operable by keyboard controls that this criterion applies. -

- -
-
- -

Size of the indicator

- - -

The bigger the visible change the easier it is for someone to see, authors are encouraged - to make the change as large as possible. For example, a thick outline around the element. -

- - -
- Three links on a white background with the middle one encompassed in a thick black border. - -
Figure 1A strong indicator around a link.
- -
- - -

To determine the minimum size for conformance purposes you would need to measure the - size of the element. -

- - -
-
Note
-

A CSS pixel is what developers use in CSS declarations like “width: 200px”, it is device-independent - and not to be confused with device pixels which vary depending on the physical pixel - density.
- The rest of this document notates CSS pixels as "px". - -

-
- - -

To establish if a focus indicator has a size equivalent to at least a 2px line along - the longest side: If a link is 90px wide by 30px tall, the indicator would need to - be have a minimum area of 180px square. (I.e. 2px wide along the longest side is 2 - x 90px.) -

- - -

The following 3 examples use a 90px wide by 30px tall button, therefore the surface - area requirement is 180px. The middle button is focused in each example. -

- - -
- Three dark blue buttons on a white background. The middle button has a yellow inner border. - -
Figure 2The inner outline is slightly smaller than the outer edge of the component, but using - a 2px thick indicator means it is well over the minimum requirement of 180px squared. -
- -
- - -
- Three dark blue buttons on a white background. The middle button has a thick yellow line under the text. - -
Figure 3The thick (3px) yellow underline is almost as long as the longest edge therefore meets - the requirment. -
- -
- - -
- Three dark blue buttons on a white background. The middle button has a yellow square to the left of the text. - -
Figure 4The 14px by 14px yellow square is 196px therefore meets the requirment.
- -
- - -

If controls change size across different variations of a page (e.g. in a responsive - design), it helps to use a proportionally sized indicator such as an outline or background - change. In that way you can be sure of meeting the size requirement. -

- - -

If controls change size and you use a fixed size indicator (such as an icon of a fixed - size) you would need to calculate the largest size a control could be in order to - provide an indicator that meets the size requirement across variations. -

- - -

Typical focus indicators:

- -
    - -
  • An outline around the whole component would pass the size requirement;
  • - -
  • Changing the background of a control would pass the size requirement;
  • - -
  • A 1px wide vertical line (such as a blinking cursor) would not pass the size requirement, a text input would need a larger or separate focus indicator. -
  • - -
- - -

If you need to use complex mathematics to work out if a focus indicator is large enough, - it is probably a sign that you should use a larger and proportional indicator that - will provide a more visible indicator. -

- - -
- -

Unusual shapes and gradients

- - - -

If you have an unusal shape, some mathematics may be required if the focus indicator - is on the edge of the size requirement. For example, if the focusable control is a - circle with a diameter of 100px, the bounding box of that component would be a square - of 100px on each side. If the focus indicator is also circular, then the area needs - to 100px * 2 = 200px. -

- - -
- Two orange circlular buttons with an icon in the middle. The right hand circle has a dark outline around the whole cicle to indicate focus - -
Figure 5A circular button in the default state, and then with a focus indicator.
- -
- - -

The circumference of a 100px diameter circle would be 314px (diameter * π), therefore - a 1px outline around the cicle will be 314px of surface area, meeting the requirement - for a 200px surface area. -

- - -

If a focus indicator is an irregular shape, such as a drop-shadow under a star icon, - it helps if the contrasting area is obviously quite large. -

- - -
- Two yellow star symbols, the second has a dark drop-shadow. - -
Figure 6The default and focused states of a star component.
- -
- - -

What is the contrasting area of the drop shadow? The quick method is:

- -
    - -
  • Look at the size of the component, and imagine a box around it, how long is the longest - edge? -
  • - -
  • Look at the (contrasting) area of the focus indicator.
  • - -
  • Mentally compare the focus indicator to the length of the longest edge * 2px.
  • - -
- - -

If it is too close to call, you could extract the contrasting area of the focus indicator - and evaluate the surface area. -

- - -

If a focus indicator has a gradient, the principle is to measure the contrast of the - changed area, and ignore the change that does not me 3:1. -

- -
- Three buttons, the middle with a heavy drop-shadow indicating focus. - -
Figure 7When a gradient is used on a focus indictor, the measure of surface area should only - include the area that has changed enough to meet the 3:1 contrast ratio. -
- -
- -

If you take some spot-checks on the gradient area and establish what area meets the - contrast, it is straightforward to work out if that area is sufficient. -

- -
- The middle button with the drop-shadow included, but the subtle grey areas removed to only show the contrasting area. - -
Figure 8The focused button with the non-contrasting areas removed, showing that it is a thick - indicator that meets the requirements. -
- -
- - - -
- -
-
- -

Contrast or thickness

- - -

Where a control is a solid color, and you add a border or outline of a very similar - color, it is difficult to perceive the change to the control. -

- - -
- Three dark buttons, the middle one appears very slightly larger due to a thin dark outline. - -
Figure 9Adding a 1px dark outline around a dark button does not differentiate it, this example - fails the success criteria. -
- -
- - -

The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent - colors (including the component), or to be separated from the component, or to be - at least 2px thick. -

- - -
- Three dark buttons, the middle one appears larger due to a thick dark outline. - -
Figure 10Adding a 2px border around the button helps to differentiate which one is focused.
- -
- - -
- Three dark buttons, the middle one has a outline slightly offset away from the component, so there is a gap between the component's background and the outline. - -
Figure 11Adding an outline that is separated from the button helps to differentiate which one - is focused. -
- -
- - -
-
- -

Change of color

- - -

The greater the change of contrast between states the easier it is for users to see - it. Authors are encouraged to make the change of color contrast as great as possible. -

- - -

When a component changes to include a focus indicator, that change can always be measured - as a change of color contrast. For example, if a yellow outline is added to a button - on a blue background, the change of color is from blue to yellow. -

- - -
-
Note
-

Color contrast measurements in WCAG are based on luminance (brightness) regardless - of the hue. -

-
- -
- Three dark blue buttons on a white background. The middle button has a yellow inner border. - -
Figure 12Adding a yellow outline to a link is a change of color from blue to yellow. That change - has a contrast ratio of 12:1. -
- -
- - - -

Text and non-text contrast measures use adjacent colors, this success criterion measures - the change in color between non-focused and focused states. -

- - -
- Three buttons with light background and dark border on a white backround. The middle button has a light grey outline. - -
Figure 13The second link has a light-grey (#ccc) focus outline which fails this success criterion because the change from white-background to light-grey outline - does not meet 3:1. -
- -
- - -
-
- -

Relation to non-text color contrast

- -

Success Criterion 1.4.11 Non-text contrast requires that a UI component maintains contrast across it’s states, including when - focused. For example, a checkbox must contrast with its adjacent colors, and the check - within the checkbox must contrast with its adjacent colors. -

- - -

Focus-visible (enhanced) requires that the change of color contrast for the focus - indicator (only) has contrast compared to the non-focused component. -

- - -
- Four checkboxes. Unchecked is a plain box. Focused has a circular line outside. Checked is dark green with a white tick. Focused and checked also has a dark green circle around it. - -
Figure 14Four checkboxes in different combinations of checked and focused. The circular indicators - (lines) provide a sufficient change of color contrast. -
- -
- - -

In the example above:

- -
    - -
  • The checkbox has sufficient contrast with its adjacent background in default, focused, - checked, and checked-focused states; -
  • - -
  • The check (tick) within the checkbox contrasts with its adjacent color;
  • - -
  • The circular outline around the checkbox that indicates focus has a sufficient change of contrast. -
  • - -
- - -
- Two checkboxes, the second has a dark blue outline around it. - -
Figure 15A default checkbox and a focused checkbox.
- -
- - -

The contrast of the default checkbox passes 1.4.11 because the dark border and white - background have a contrast ratio greater than 3:1. The 2px dark blue focus outline - passes Focus Visible (Enhanced) because the change of contrast is greater than 3:1 - with the white background. The component as a whole maintains contrast with the white - background so continues to pass 1.4.11. -

- - -
-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G195: Using an author-supplied, highly visible focus indicator - -
  2. - -
  3. - C40: Creating a two-color focus indicator to ensure sufficient contrast with all components - -
  4. - -
  5. - C41: Creating a focus indicator within the component - -
  6. - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

- -
-
-
-

Key Terms

-
css pixel
-
- - - -

visual angle of about 0.0213 degrees

- - -

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. - This unit is density-independent, and distinct from actual hardware pixels present - in a display. User agents and operating systems should ensure that a CSS pixel is - set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[!css3-values]], which takes into account the physical dimensions of the display - and the assumed viewing distance (factors that cannot be determined by content authors). - -

- - -
-
-
focus
-
- - - - -

The point where the user’s input interacts with the web page. For example, tabbing - through a page with a keyboard moves the focus. Clicking or tapping on the page would - move the focus for mouse and touchscreen usage. Different inputs can be used by a - user, but at any one time there would be one point of focus for the user with the - last input used. - -

- - -
-
-
focus indication area
-
- - - -

The number of CSS pixels that change between the focused and unfocused states of a - User Interface Component. - -

- - -
-
-
user interface component
-
- - - -

a part of the content that is perceived by users as a single control for a distinct - function - -

- - -
-
Note
-

Multiple user interface components may be implemented as a single programmatic element. - Components here is not tied to programming techniques, but rather to what the user - perceives as separate controls. - -

-
- - -
-
Note
-

User interface components include form elements and links as well as components generated - by scripts. - -

-
- - -
-
Note
-

What is meant by "component" or "user interface component" here is also sometimes - called "user interface element". - -

-
- - -

An applet has a "control" that can be used to move through content by line or page - or random access. Since each of these would need to have a name and be settable independently, - they would each be a "user interface component." - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/hidden-controls.html b/understanding/hidden-controls.html deleted file mode 100644 index ef63023715..0000000000 --- a/understanding/hidden-controls.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - - Understanding Success Criterion 3.2.7: Hidden Controls - - - - - - - - -

Understanding Success Criterion 3.2.7: Hidden Controls

-
-

Success Criterion 3.2.7 Hidden Controls (Level AA): Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard - focus, - or a mechanism is available to make them persistently visible. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The intent of this Success Criterion is to ensure that controls needed to progress - or complete a process can be easily found by people with cognitive disabilities when - they are needed. -

-

People with low executive function, impaired memory, and other cognitive and learning - disabilities may not be able to find controls needed to progress if they are hidden - until focus is placed on them or a pointer hovers over them. They may also not remember - where the control is the next time they interact with the site. -

-

Some design approaches hide controls needed to complete tasks and require certain - user interactions, such as mouse-over, to display these controls. These required interactions - can leave users with cognitive disabilities without a path forward. -

-

Controls should be visible without user interaction (i.e., persistently visible) when - they are needed to progress. In multistep processes or multipart forms, the control - may be hidden in an earlier step/part, however, at the time the user can move forward - the control needs to be persistently visible without having interacted with the control. - Similarly, this SC does not require inactive controls to be persistently visible until - the user is able to progress. For example, when a form includes required fields be - completed before the submit button becomes active, the submit button does not need - to be persistently visible while it is inactive. -

-

When multiple controls are included in a single location, some indication of those - controls such as a drop down indicator should be visible without user interaction. - -

-

In some cases, controls are provided in multiple locations on a page or at multiple - points within a process. In these cases, at least one of the instances of the controls - needs to be visible without user interaction. For example, in an email process, some - controls such as trash may be visible using pointer hover in the list of emails but - are always visible on the view of the email itself. Because the controls are persistently - visible when needed on the email view, they do not need to persistently visible on - the list of emails. -

-

The intent of this SC is to help individuals with cognitive and learning disabilities - locate controls they need to successfully complete their desired task. The controls - addressed in this SC should also meet the SC for sufficient text (1.4.3/1.4.6) and - non-text (1.4.11) contrast. -

-

Controls such as video players, web chats, and carousels include controls that are - only visible on hover since they overlay the contents being displayed. These controls - are not considered a process in terms of this SC but occasionally completing a process - requires interacting with one of these controls. For example, completing training - may require the user watch a video before proceeding to the next step. In this case, - a control needed to play the video needs to be visibly persistent. This may be accomplished - by making the video controls all visibly persist or by adding a redundant play control - to the page. -

-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - Provide persistently visible controls - -
  2. - - - -
  3. Use simplification=”important” to indicate the control is important (future) - -
  4. - -
-
-
-
-

Key Terms

-
process
-
- - - -

series of user actions where each action is required in order to complete an activity

- - -

Successful use of a series of Web pages on a shopping site requires users to view - alternative products, prices and offers, select products, submit an order, provide - shipping information and provide payment information. - -

- - -

An account registration page requires successful completion of a Turing test before - the registration form can be accessed. - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/img/focus-indicator-checkboxs.png b/understanding/img/focus-indicator-checkboxs.png deleted file mode 100644 index 933ef9982d..0000000000 Binary files a/understanding/img/focus-indicator-checkboxs.png and /dev/null differ diff --git a/understanding/img/focus-indicator-checked.png b/understanding/img/focus-indicator-checked.png deleted file mode 100644 index a3ed176405..0000000000 Binary files a/understanding/img/focus-indicator-checked.png and /dev/null differ diff --git a/understanding/img/focus-indicator-circle.png b/understanding/img/focus-indicator-circle.png deleted file mode 100644 index 61fccb8621..0000000000 Binary files a/understanding/img/focus-indicator-circle.png and /dev/null differ diff --git a/understanding/img/focus-indicator-extra-outline.png b/understanding/img/focus-indicator-extra-outline.png deleted file mode 100644 index 1810f48f4b..0000000000 Binary files a/understanding/img/focus-indicator-extra-outline.png and /dev/null differ diff --git a/understanding/img/focus-indicator-icon.png b/understanding/img/focus-indicator-icon.png deleted file mode 100644 index 28d8903d01..0000000000 Binary files a/understanding/img/focus-indicator-icon.png and /dev/null differ diff --git a/understanding/img/focus-indicator-non-contrast.png b/understanding/img/focus-indicator-non-contrast.png deleted file mode 100644 index c4cabe344c..0000000000 Binary files a/understanding/img/focus-indicator-non-contrast.png and /dev/null differ diff --git a/understanding/img/focus-indicator-ntc-comparison1.png b/understanding/img/focus-indicator-ntc-comparison1.png deleted file mode 100644 index fc0a1fa38f..0000000000 Binary files a/understanding/img/focus-indicator-ntc-comparison1.png and /dev/null differ diff --git a/understanding/img/focus-indicator-outerline.png b/understanding/img/focus-indicator-outerline.png deleted file mode 100644 index 873775989e..0000000000 Binary files a/understanding/img/focus-indicator-outerline.png and /dev/null differ diff --git a/understanding/img/focus-indicator-star-shadow.png b/understanding/img/focus-indicator-star-shadow.png deleted file mode 100644 index 8717f2642a..0000000000 Binary files a/understanding/img/focus-indicator-star-shadow.png and /dev/null differ diff --git a/understanding/img/focus-indicator-star-with-abutted-line.svg b/understanding/img/focus-indicator-star-with-abutted-line.svg deleted file mode 100644 index 595e447fed..0000000000 --- a/understanding/img/focus-indicator-star-with-abutted-line.svg +++ /dev/null @@ -1,7 +0,0 @@ - - - - - - - \ No newline at end of file diff --git a/understanding/img/focus-indicator-strong-dashed-border.svg b/understanding/img/focus-indicator-strong-dashed-border.svg deleted file mode 100644 index 8852e04f03..0000000000 --- a/understanding/img/focus-indicator-strong-dashed-border.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/understanding/img/focus-indicator-strong.png b/understanding/img/focus-indicator-strong.png deleted file mode 100644 index 0042c3157a..0000000000 Binary files a/understanding/img/focus-indicator-strong.png and /dev/null differ diff --git a/understanding/img/focus-indicator-thick-non-contrast.png b/understanding/img/focus-indicator-thick-non-contrast.png deleted file mode 100644 index 43f0d7fe48..0000000000 Binary files a/understanding/img/focus-indicator-thick-non-contrast.png and /dev/null differ diff --git a/understanding/img/focus-indicator-thick-short-side.png b/understanding/img/focus-indicator-thick-short-side.png deleted file mode 100644 index b72d6de934..0000000000 Binary files a/understanding/img/focus-indicator-thick-short-side.png and /dev/null differ diff --git a/understanding/img/focus-indicator-thin-non-contrast.png b/understanding/img/focus-indicator-thin-non-contrast.png deleted file mode 100644 index 865cad28ec..0000000000 Binary files a/understanding/img/focus-indicator-thin-non-contrast.png and /dev/null differ diff --git a/understanding/img/focus-indicator-underline.png b/understanding/img/focus-indicator-underline.png deleted file mode 100644 index ebebb58518..0000000000 Binary files a/understanding/img/focus-indicator-underline.png and /dev/null differ diff --git a/understanding/img/focus-indicator-weak-dashed-border.svg b/understanding/img/focus-indicator-weak-dashed-border.svg deleted file mode 100644 index 1600f1f080..0000000000 --- a/understanding/img/focus-indicator-weak-dashed-border.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/understanding/img/visibe-control-meeting-control-hidden.png b/understanding/img/visibe-control-meeting-control-hidden.png deleted file mode 100644 index 870c55ab12..0000000000 Binary files a/understanding/img/visibe-control-meeting-control-hidden.png and /dev/null differ diff --git a/understanding/img/visible-control-edit-menu-hidden.png b/understanding/img/visible-control-edit-menu-hidden.png deleted file mode 100644 index 47d0fc884c..0000000000 Binary files a/understanding/img/visible-control-edit-menu-hidden.png and /dev/null differ diff --git a/understanding/page-break-navigation.html b/understanding/page-break-navigation.html deleted file mode 100644 index e27b87a365..0000000000 --- a/understanding/page-break-navigation.html +++ /dev/null @@ -1,503 +0,0 @@ - - - - - Understanding Success Criterion 2.4.14: Page Break Navigation - - - - - - - - -

Understanding Success Criterion 2.4.14: Page Break Navigation

-
-

Success Criterion 2.4.14 Page Break Navigation (Level A): For web content with page break locators, a mechanism is available to navigate to each locator. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The purpose of this Success Criterion is to let all users locate the same content - using page break locators, regardless of whether they use print or digital versions of a publication. This - is important to users with disabilities who may transform the information to more - easily consume it. -

-

Page numbering has long been a fundamental way to identify and communicate the location - of specific parts of published content. Page numbers are used in references, footnotes, - endnotes, bibliographies, and tables of content. Particularly, they are critical in - academic and learning environments. When participants use the same edition of a printed - book, page numbers provide a means to ensure everyone is "on the same page." -

-

Digital publishing, while providing greater access to information, threatens the ability - for everyone to locate information by page number. This is because screen size and - user preferences can alter content. In one implementation, a screen of content may - be considered a page, and the pagination may be updated to match the number of screens - of content on a specific device. In another, the page numbering may cease to be used - at all in a digital version. In either case, a user whose page numbering no longer - matches the printed version cannot easily locate information by page number references. - -

-

Digital publishing provides crucial access to content for people who are blind, have - low vision, dyslexia or other cognitive disabilities. Such users are likely to adapt - content by using a different layout or assistive technology. Providing a mechanism - by which users of digital versions can navigate via page numbers, ensures all users - can easily reach the same document location. -

-

The scope of this criterion is web content that is part of a Web page. EPUB can fulfill this definition if it is available to read at a URI. The more common - case that is in scope is an EPUB book converted to be read by a web browser. -

-
-
Note
-

In publishing, there can be many different editions of a work, such as a second edition - or a paperback edition. There is a requirement (separate from accessibility) for metadata - in digital publications like EPUB to identify the edition of the title which a digital - version represents. The page break locaters would be aligned with the specified edition. -

-
-
-
Note
-

Statically paginated formats (such as PDF) where the user agents include a mechanism - to navigate by page typically meet this Success Criterion by default. The user agents - for the EPUB format also typically provide the navigation mechanism if a page list - is included. Web browsers do not have a standard page navigation mechanism, so for - HTML content with page break locators it is the author responsibility to add that - mechanism. -

-
-
-
Note
-

For a Page Break Locator to be a "programmatically determinable destination marker", - it needs to have a role that identifies it as a page break, and a method of determining - which page in a sequence it represents. This Criterion applies to pages which include - elements with the doc-pagebreak semantic role and an associated ID attribute. H99: Provide a page-selection mechanism shows how this can be accomplished. This would not apply to an element which visually - shows a page number, unless it also has a recognized role. This Success Criterion - is also not concerned with how the web page prints out. Mark up to control output - for printing, such as CSS page breaks, is not in scope. -

-
-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Related Resources

-

Resources are for information purposes only, no endorsement implied.

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - H99: Provide a page-selection mechanism - -
  2. - -
-
-
-
-

Key Terms

-
assistive technology
-
- - - -

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements - of users with disabilities that go beyond those offered by mainstream user agents - -

- - -
-
Note
-

functionality provided by assistive technology includes alternative presentations - (e.g., as synthesized speech or magnified content), alternative input methods (e.g., - voice), additional navigation or orientation mechanisms, and content transformations - (e.g., to make tables more accessible). - -

-
- - -
-
Note
-

Assistive technologies often communicate data and messages with mainstream user agents - by using and monitoring APIs. - -

-
- - -
-
Note
-

The distinction between mainstream user agents and assistive technologies is not absolute. - Many mainstream user agents provide some features to assist individuals with disabilities. - The basic difference is that mainstream user agents target broad and diverse audiences - that usually include people with and without disabilities. Assistive technologies - target narrowly defined populations of users with specific disabilities. The assistance - provided by an assistive technology is more specific and appropriate to the needs - of its target users. The mainstream user agent may provide important functionality - to assistive technologies like retrieving Web content from program objects or parsing - markup into identifiable bundles. - -

-
- - -

Assistive technologies that are important in the context of this document include - the following: - -

- - -
    - - -
  • screen magnifiers, and other visual reading assistants, which are used by people with - visual, perceptual and physical print disabilities to change text font, size, spacing, - color, synchronization with speech, etc. in order to improve the visual readability - of rendered text and images; - -
  • - - -
  • screen readers, which are used by people who are blind to read textual information - through synthesized speech or braille; - -
  • - - -
  • text-to-speech software, which is used by some people with cognitive, language, and - learning disabilities to convert text into synthetic speech; - -
  • - - -
  • speech recognition software, which may be used by people who have some physical disabilities;
  • - - -
  • alternative keyboards, which are used by people with certain physical disabilities - to simulate the keyboard (including alternate keyboards that use head pointers, single - switches, sip/puff and other special input devices.); - -
  • - - -
  • alternative pointing devices, which are used by people with certain physical disabilities - to simulate mouse pointing and button activations. - -
  • - - -
- - -
-
-
conformance
-
- - - -

satisfying all the requirements of a given standard, guideline or specification

- - -
-
-
mechanism
-
- - - -

- process or technique for achieving a result - -

- - -
-
Note
-

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. - -

-
- - -
-
Note
-

The mechanism needs to meet all success criteria for the conformance level claimed.

-
- - -
-
-
page break locators
-
- - - - -

- programmatically determinable destination markers that are arranged in a meaningful sequence to represent a locator - serving the same purpose as page breaks in a printed document. -

- -

Examples would be:

- -
    - -
  • A digital version of an ebook that has a print version, it includes the page break - locators to align with the print edition. -
  • - -
  • A digital book is published with no print equivalent and page break locators are inserted - which supports direct navigation across platforms and form factors. -
  • - -
- - -
-
-
process
-
- - - -

series of user actions where each action is required in order to complete an activity

- - -

Successful use of a series of Web pages on a shopping site requires users to view - alternative products, prices and offers, select products, submit an order, provide - shipping information and provide payment information. - -

- - -

An account registration page requires successful completion of a Turing test before - the registration form can be accessed. - -

- - -
-
-
programmatically determined
-
- - - -

determined by software from author-supplied data provided in a way that different - user agents, including assistive technologies, can extract and present this information to users in different modalities - -

- - -
-
Note
-

Determined in a markup language from elements and attributes that are accessed directly - by commonly available assistive technology. - -

-
- - -
-
Note
-

Determined from technology-specific data structures in a non-markup language and exposed - to assistive technology via an accessibility API that is supported by commonly available - assistive technology. - -

-
- - -
-
-
relied upon
-
- - - -

the content would not conform if that technology is turned off or is not supported - -

- - -
-
-
technology
-
- - - -

- mechanism for encoding instructions to be rendered, played or executed by user agents - -

- - -
-
Note
-

As used in these guidelines "Web Technology" and the word "technology" (when used - alone) both refer to Web Content Technologies. - -

-
- - -
-
Note
-

Web content technologies may include markup languages, data formats, or programming - languages that authors may use alone or in combination to create end-user experiences - that range from static Web pages to synchronized media presentations to dynamic Web - applications. - -

-
- - -

Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, - Flash, and JavaScript. - -

- - -
-
-
user agent
-
- - - -

any software that retrieves and presents Web content for users

- - -

Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving, rendering, and interacting with Web content. - -

- - -
-
-
web page
-
- - - -

a non-embedded resource obtained from a single URI using HTTP plus any other resources - that are used in the rendering or intended to be rendered together with it by a user agent - -

- - -
-
Note
-

Although any "other resources" would be rendered together with the primary resource, - they would not necessarily be rendered simultaneously with each other. - -

-
- - -
-
Note
-

For the purposes of conformance with these guidelines, a resource must be "non-embedded" - within the scope of conformance to be considered a Web page. - -

-
- - -

A Web resource including all embedded images and media.

- - -

A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program - lives entirely at http://example.com/mail, but includes an inbox, a contacts area - and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar - to display, but do not change the URI of the page as a whole. - -

- - -

A customizable portal site, where users can choose content to display from a set of - different content modules. - -

- - -

When you enter "http://shopping.example.com/" in your browser, you enter a movie-like - interactive shopping environment where you visually move around in a store dragging - products off of the shelves around you and into a visual shopping cart in front of - you. Clicking on a product causes it to be demonstrated with a specification sheet - floating alongside. This might be a single-page Web site or just one page within a - Web site. - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/pointer-target-spacing.html b/understanding/pointer-target-spacing.html deleted file mode 100644 index a50cd97d1d..0000000000 --- a/understanding/pointer-target-spacing.html +++ /dev/null @@ -1,507 +0,0 @@ - - - - - Understanding Success Criterion 2.5.8: Pointer Target Spacing - - - - - - - - -

Understanding Success Criterion 2.5.8: Pointer Target Spacing

-
-

Success Criterion 2.5.8 Pointer Target Spacing (Level AA): For each target, there is an area with a width and height of at least 44 CSS pixels that includes - it, and no other targets, except when: -

- -

This criterion has been formulated to increase the hit-area of small targets, but - the group would like feedback from providers of touch-screen devices if there is another - way of forming the criterion to better complement the tap-heuristics used. -

-

Are there issues with internationalization when describing inline links?

-

Are there issues with pop-over content overlapping targets triggering failures?

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The intent of this Success Criterion is to ensure targets can easily be activated - without accidentally activating an adjacent target. When targets are small, it is - difficult for users with hand tremors and those who have difficulty with fine motor - movement to activate them accurately. Providing spacing between targets will reduce - the likelihood of accidentally activating the wrong control. -

-

The requirement is for targets that are smaller than 44 x 44px to be included in an - area with a width and height of at least 44px each. For the horizontal dimension, - this means that the total width of 44px is composed of the width of the target and - the width of the spacing that separates it from adjacent targets. The same applies - to the height. For example, a target of 24 x 24px would meet the requirement if it - had a spacing of 10 px on all sides. If the target is 44 x 44px or larger, no spacing - between it and adjacent targets would be required. -

-

There are three exceptions:

-
    - -
  1. If there is a mechanism to change the target sizes or spacing to meet the minimum, - such as a button to change the sizes and layout of the targets. -
  2. - -
  3. If the target is inline within a sentence there doesn’t need to be a minimum target - size. -
  4. - -
  5. If the spacing of the targets is essential to the information being conveyed there - doesn’t need to be a minimum target size. -
  6. - -
-

The requirement is independent of the zoom factor of the page, when users zoom in - the CSS pixel size of elements does not change. This means that authors cannot meet - it by claiming that the target will have enough spacing or sufficient size if the - user zooms into the page. -

-

The requirement does not apply to the spacing of targets inside unstyled native elements. - For example, when a default select element is used, the vertical spacing of option - elements inside the select's dropdown list is exempt. -

-

While the Success Criterion primarily helps touch users by ensuring that activation - with the 'fat finger' will not accidentally trigger adjacent targets, it is also useful - for mouse or pen users. It reduces the chances of erroneous activation due to a tremor - or some other input imprecision. -

-

As mobile devices generally have internal heuristics to identify which link is closest, - spacing can work as effectively as a larger target size. -

-
- A series of icons with measures showing they are each 44 by 44 pixels wide and high. - -
Figure 1 The dimension of each icon target in a row is 44 by 44 CSS pixels, so the targets - pass this Success Criterion without additional spacing. -
- -
-
- A row of icons with measures showing they are each 38 by 38 pixels wide and high, with 6 pixel spacing between them. - -
Figure 2 The dimension of each icon target in a row is 38 by 38 CSS pixels, so a spacing of - 6 CSS pixels is required to arrive at 44 CSS pixels for the combined width and spacing - of the target. No adjacent targets are present above and below, i.e., there is sufficient - vertical spacing for the height of 38 CSS pixels to be sufficient. -
- -
-
- A row of buttons which are more that 44px wide and 20px high. There are no targets above or below. - -
Figure 3 The widths of the button with adjacent neighbors is at least 44 CSS pixels, while - the height is only 22 CSS pixels. The target height combined with the vertical spacing - above and below exceeds 44 CSS pixels, therefore, the targets pass this Success Criterion. -
- -
-
- A row of icons which are 44px wide and 20px high, with other targets above and below with only 2px spacing. - -
Figure 4 Fail: Two rows of buttons, all with a height of only 20 CSS pixels. In the top row, buttons - all have a width of more than 44 CSS pixels. For the top row, targets above and below - are in close proximity. The top spacing of the first row is 4 px while the bottom - spacing is 2 px, which adds up to 26 px for target height and vertical spacing combined. - Therefore, the buttons in the top row fail the Success Criterion. The button "Pop" - in the second row is only 32px wide with no horizontal spacing, so it also fails the - Success Criterion even when there is sufficient space below to meet the vertical spacing - requirement. -
- -
-

Where targets are embedded inside other targets, the inner target either needs a size - of at least 44 x 44 CSS pixels or must be placed at the edge or corner to make sure - that there is sufficient adjacent spacing in each dimension. -

-
- Three examples of a target adjacent to another target (see legend below) - -
Figure 5 Three examples of a person's profile image, which is supposed to be a target leading - to another page, and a magnifying glass icon, which is supposed to open a lightbox - view of the profile image. In the first example, the magnifying icon is outside the - picture and passes. In the second example, the icon overlaps with the top-left corner - of the image, but passes due to sufficient spacing top and left. In the third example, - the icon sits inside the linked image. Since it is surrounded by an active click area, - the icon target is not large enough to pass the success criterion. -
- -
-

Users with different disabilities have different needs for control sizes. It can be - beneficial to provide an option to increase the active target area without increasing - the visible target size. Another option is to provide a mechanism to control the density - of layout and thereby change target size or spacing, or both. This can be beneficial - for a wide range of users. For example, users with visual field loss may prefer a - more condensed layout with smaller sized controls while users with other forms of - low vision may prefer large controls. -

-

Where user-agents control the size of a target, such as the options in a select drop-down, and the author has not tried to change the size of target with size or - padding adjustments, the target is exempted from this criterion. It would be beneficial - for users if the minimum size & spacing requirement is met, but where the user-agent - has defined the target it is not the authors responsibility. -

-
-
-

Benefits

-

Having targets with sufficient target spacing can help all users who may have difficulty - in confidently targeting or operating small controls. Users who benefit include, but - are not limited to: -

- -
-
-

Examples

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - C42: Using min-height and min-width to ensure sufficient target spacing - -
  2. - -
-
-
-
-

Key Terms

-
assistive technology
-
- - - -

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements - of users with disabilities that go beyond those offered by mainstream user agents - -

- - -
-
Note
-

functionality provided by assistive technology includes alternative presentations - (e.g., as synthesized speech or magnified content), alternative input methods (e.g., - voice), additional navigation or orientation mechanisms, and content transformations - (e.g., to make tables more accessible). - -

-
- - -
-
Note
-

Assistive technologies often communicate data and messages with mainstream user agents - by using and monitoring APIs. - -

-
- - -
-
Note
-

The distinction between mainstream user agents and assistive technologies is not absolute. - Many mainstream user agents provide some features to assist individuals with disabilities. - The basic difference is that mainstream user agents target broad and diverse audiences - that usually include people with and without disabilities. Assistive technologies - target narrowly defined populations of users with specific disabilities. The assistance - provided by an assistive technology is more specific and appropriate to the needs - of its target users. The mainstream user agent may provide important functionality - to assistive technologies like retrieving Web content from program objects or parsing - markup into identifiable bundles. - -

-
- - -

Assistive technologies that are important in the context of this document include - the following: - -

- - -
    - - -
  • screen magnifiers, and other visual reading assistants, which are used by people with - visual, perceptual and physical print disabilities to change text font, size, spacing, - color, synchronization with speech, etc. in order to improve the visual readability - of rendered text and images; - -
  • - - -
  • screen readers, which are used by people who are blind to read textual information - through synthesized speech or braille; - -
  • - - -
  • text-to-speech software, which is used by some people with cognitive, language, and - learning disabilities to convert text into synthetic speech; - -
  • - - -
  • speech recognition software, which may be used by people who have some physical disabilities;
  • - - -
  • alternative keyboards, which are used by people with certain physical disabilities - to simulate the keyboard (including alternate keyboards that use head pointers, single - switches, sip/puff and other special input devices.); - -
  • - - -
  • alternative pointing devices, which are used by people with certain physical disabilities - to simulate mouse pointing and button activations. - -
  • - - -
- - -
-
-
conformance
-
- - - -

satisfying all the requirements of a given standard, guideline or specification

- - -
-
-
mechanism
-
- - - -

- process or technique for achieving a result - -

- - -
-
Note
-

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. - -

-
- - -
-
Note
-

The mechanism needs to meet all success criteria for the conformance level claimed.

-
- - -
-
-
process
-
- - - -

series of user actions where each action is required in order to complete an activity

- - -

Successful use of a series of Web pages on a shopping site requires users to view - alternative products, prices and offers, select products, submit an order, provide - shipping information and provide payment information. - -

- - -

An account registration page requires successful completion of a Turing test before - the registration form can be accessed. - -

- - -
-
-
relied upon
-
- - - -

the content would not conform if that technology is turned off or is not supported - -

- - -
-
-
target
-
- - - -

region of the display that will accept a pointer action, such as the interactive area - of a user interface component -

- -
-
Note
-

If two or more touch targets are overlapping, the overlapping area should not be included - in the measurement of the target size, except when the overlapping targets perform - the same action or open the same page. -

-
- - -
-
-
technology
-
- - - -

- mechanism for encoding instructions to be rendered, played or executed by user agents - -

- - -
-
Note
-

As used in these guidelines "Web Technology" and the word "technology" (when used - alone) both refer to Web Content Technologies. - -

-
- - -
-
Note
-

Web content technologies may include markup languages, data formats, or programming - languages that authors may use alone or in combination to create end-user experiences - that range from static Web pages to synchronized media presentations to dynamic Web - applications. - -

-
- - -

Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, - Flash, and JavaScript. - -

- - -
-
-
user agent
-
- - - -

any software that retrieves and presents Web content for users

- - -

Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving, rendering, and interacting with Web content. - -

- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/target-size.html b/understanding/target-size.html deleted file mode 100644 index f637623cb6..0000000000 --- a/understanding/target-size.html +++ /dev/null @@ -1,339 +0,0 @@ - - - - - Understanding Success Criterion 2.5.5: Target Size - - - - - - - - -

Understanding Success Criterion 2.5.5: Target Size

-
-

Success Criterion 2.5.5 Target Size (Level AAA): The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when: -

-
- -
Equivalent
- -
The target is available through an equivalent link or control on the same page that - is at least 44 by 44 CSS pixels; -
- -
Inline
- -
The target is in a sentence or block of text;
- -
User Agent Control
- -
The size of the target is determined by the user agent and is not modified by the - author; -
- -
Essential
- -
A particular presentation of the target is essential to the information being conveyed. -
- -
-
-
-
-

Intent

-

The intent of this success criterion is to ensure that target sizes are large enough - for users to easily activate them, even if the user is accessing content on a small - handheld touch screen device, has limited dexterity, or has trouble activating small - targets for other reasons. For instance, mice and similar pointing devices can be - hard to use for these users, and a larger target will help them activate the target. -

-

Touch is particularly problematic as it is an input mechanism with coarse precision. - Users lack the same level of fine control when using inputs such as a mouse or stylus. - A finger is larger than a mouse pointer, and generally obstructs the user's - view of the precise location on the screen that is being touched/activated. -

-

The issue can even be further complicated with responsive layouts on small screens - like mobile, which need to accommodate different types of fine and coarse inputs. - Both input types must be supported for a site that can be accessed both on a traditional - desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen. -

-

While this criterion defines a minimum target size, as a best practice it is recommended - that larger sizes are used to reduce the possibility of unintentional activations. - This is particularly relevant if any of the following are true: -

- -

The targets on a screen can have different purposes and uses, and this Success Criterion - specifies how each is to be handled. -

-

Equivalent targets: If there is more than one target on a screen that performs the same action, only - one of the targets need to meet the target size of 44 by 44 CSS pixels. -

-

Inline: Content displayed can often be reflowed based on the screen width available. This - is known as responsive design and makes it easier to read since you do not need to - scroll both horizontally and vertically. In reflowed content, - the targets can appear anywhere on a line and can change position based on the width - of the available screen. Since targets can appear anywhere on the line, the size cannot - be larger than the available text and spacing between the sentences or paragraphs, - otherwise the targets could overlap. It is for this reason targets which are contained - within one or more sentences are excluded from the target size requirements. -

-
-
Note
-

If the target is the full sentence and the sentence is not in a block of text, then - the target needs to be at least 44 by 44 CSS pixels. -

-
-
-
Note
-

A footnote or an icon within or at the end of a sentence is considered to be part - of a sentence and therefore are excluded from the minimum target size. -

-
-

User Agent Control: If the size of the target is not modified by the author through CSS or other size - properties, then the target does not need to meet the target size of 44 by 44 CSS - pixels. -

-

Essential: If the target is required to be a particular target size and cannot be provided in - another way, while changing it would essentially change the information or functionality - of the content, then the target does not need to - meet the target size of 44 by 44 CSS pixels. -

-
-
-

Benefits

- -
-
-

Examples

- -
-
-

Related Resources

-

Resources are for information purposes only, no endorsement implied.

- -
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  • Ensuring that touch targets are at least 44 by 44 CSS pixels.
  • - -
  • Providing a mechanism to change the size of the target independent of magnification.
  • - -
-
-
-

Advisory Techniques

-

Although not required for conformance, the following additional techniques should - be considered in order to make content more accessible. Not all techniques can be - used or would be effective in all situations. -

-
    - -
  • Ensuring inline links provide sufficiently large activation target.
  • - -
-
-
-

Failures

-

The following are common mistakes that are considered failures of this Success Criterion - by the WCAG Working Group. -

-
    - -
  • Failure of success criterion 2.5.3 due to target size being less than 44 by 44 CSS - pixels. -
  • - -
  • Failure of success criterion 2.5.3 due to target size of a paragraph that is also - a link being less than 44 by 44 CSS pixels. -
  • - -
-
-
-
-

Key Terms

-
css pixel
-
- - - -

visual angle of about 0.0213 degrees

- - -

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. - This unit is density-independent, and distinct from actual hardware pixels present - in a display. User agents and operating systems should ensure that a CSS pixel is - set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[!css3-values]], which takes into account the physical dimensions of the display - and the assumed viewing distance (factors that cannot be determined by content authors). - -

- - -
-
-
essential
-
- - - -

if removed, would fundamentally change the information or functionality of the content, - and information and functionality cannot be achieved in another way that would conform - -

- - -
-
-
pointer input
-
- - - -

input device that can target a specific coordinate (or set of coordinates) on a screen, - such as a mouse, pen, or touch contact - -

- - -

See also Pointer Events pointer definition [[!pointerevents]]. - -

- - -
-
-
target
-
- - - -

region of the display that will accept a pointer action, such as the interactive area - of a user interface component -

- -
-
Note
-

If two or more touch targets are overlapping, the overlapping area should not be included - in the measurement of the target size, except when the overlapping targets perform - the same action or open the same page. -

-
- - -
-
-
-
- - \ No newline at end of file diff --git a/understanding/visible-controls.html b/understanding/visible-controls.html deleted file mode 100644 index fc8e7b6061..0000000000 --- a/understanding/visible-controls.html +++ /dev/null @@ -1,406 +0,0 @@ - - - - - Understanding Success Criterion 3.2.7: Visible Controls - - - - - - - - -

Understanding Success Criterion 3.2.7: Visible Controls

-
-

Success Criterion 3.2.7 Visible Controls (Level AA): When user interface components are invisible until hover or focus makes them visible, provide a visible indicator - that the components are available, except when: -

- -

User interface components can be available through other visible components such as - sub-menus, edit buttons, tabs, or thumbnails of media. -

-

The working group is interested in feedback about whether there are Components determined - by the user agent that should not be in scope. -

-
-
-
- -

Status

- -

This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published. -

- -
-
-

Intent

-

The intent of this Success Criterion is to ensure that user interface components (controls) - can be found easily by people with cognitive disabilities, vision loss, and mobility - and motor impairments. -

-

Some design approaches hide controls and require certain user interactions, such as - mouseover, to reveal them (both visually and programmatically). Where the hidden controls - are needed to complete tasks, the difficulty in discovering the controls can leave - some users with disabilities without a way to progress. -

-
- - -

Cognitive disabilities

- - -

People with low executive function, impaired memory, and other cognitive and learning - disabilities may not be able to find hidden controls. If a hidden control is needed - in order to progress, this can prevent some users from completing a task. Users who - discover controls that display on hover may not remember how to show and operate the - controls the next time they interact with the site. So even when a user is able to - proceed, time on task can be affected for both one-time and repeated uses. -

- - -
-
- - -

Vision loss

- - -

One of the main challenges for people with vision loss is simply locating related - controls on the screen, moving the mouse from control to control, and getting the - keyboard focus to coincide with where they are looking. This Success Criterion can - help reduce that cumulative load. -

- - -

People with vision loss may not see controls that display only on hover or focus, - particularly if they display outside of the viewport. For users who require enlarged - or magnified content, the portion of the content in the viewport may be significantly - reduced. Low vision users may have 800 x 600 resolution as the default. They may look - closely at the monitor from a few inches away due to limited acuity (inability to - see detail) or Scotomas (blind spots). They may have a significant amount of head - and neck movement while using content. When users don't see something on the screen, - they may assume they are missing it — for example, that it’s in their blind spot or - hidden in a menu — and go searching until they either find it or give up searching. - -

- - -
-
- - -

Mobility and motor impairments

- - -

People who use alternative input methods may have difficulty locating and operating - controls that display only on hover or focus. For example, speech recognition users - activate controls by speaking the name of the control. Functions that are only exposed - through hover interaction or keyboard focus can pose significant barriers to alternative - input methods. -

- - -
-
- - -

When Needed

- - -

Information needed to identify controls does not need to be visible all the time. - But information needed to identify controls must be visible without hover interaction - or keyboard focus when the controls are needed. For example, if the control is required to carry out a task or progress through - a user process. Controls can be available through a persistent visible entry point, such as a menu button that opens subitems. In a multi-step process or multi-part - form, controls may be hidden in an earlier step or part; however, at the time the - user can move the process forward, the information needed to identify the control, - which is usually the control itself, must be visible without hover interaction or - keyboard focus. -

- - -

Ideally the information needed to identify controls exist would be visible all the - time. Controls can be available through a persistent visible entry point, such as - a menu button that opens subitems. There are also several exceptions outlined in the - criterion text: -

- -
    - -
  • If controls are provided in multiple locations on a page or at multiple points within - a process, at least one of the instances of the control must be visible without hover - interaction or keyboard focus. For example, with an email reader some controls such - as Trash may be visible when hovering over individual messages in the inbox list view. - Those controls will always be visible on the email view so they do not need to be - persistently visible on the inbox view. -
  • - -
  • If the control is to enhance keyboard navigation. For example, a link that skips from - the top of the page to the navigation could become visible only on focus. -
  • - -
  • If there is a mechanism to make the indicators persistently visible. For example, - a button at the top of the page could make all the hidden controls visible without - needing to hover over them. -
  • - -
  • If hiding the information needed to identify the component is essential. For example, - a memory game hides the controls for selecting a card to flip over. -
  • - -
- - -

The exception for components that provide "keyboard-only functionality" is to allow - for features such as skip links, which are not visible by default. As they appear - on focus, and are aimed at keyboard-only users, they are not intended to be covered - by this criterion. -

- - -

The following images highlight when a hidden hover feature is used, and there should - be an indicator of those controls -

- - -
- Two browser windows showing a wireframe of the same music website, the right hand window has an additional control showing about the navigation. - -
Figure 1 The navigation "Edit" control becomes visible on hover, but there is no visible indicator - that it is available, so this example fails the criterion. -
- -
- - -
- Two screens showing a wireframe of an online meeting interface. The right hand screen has many additional controls showing. - -
Figure 2 The extra controls become visible on hover next to the already visible mute button. - However, there is no visible indicator that they are available, so this example fails - the criterion. -
- -
- -

If figure 1 had an edit icon (e.g. a pencil) and figure 2 used a three dots / ellipsis - icon, those would provide a visual indicator and pass the success criterion. -

- - -
-
- - - -

Embedded Controls

- - -

Information needed to identify user interface components is usually the component - itself; however, there are situations where controls are not visible. Complex components - such as video players and carousels often include controls that are visible on hover. - The presence of the complex component — for example, the carousel component or the - video image — provides the “Information needed to identify the user interface components.” - For a carousel, controls displayed on hover should also be displayed when the carousel - is activated. For a video player, activating the video image should launch the video - (sometimes in a new window), at which point more video player controls, including - controls displayed previously on hover, should be visible. Some users may still struggle - if video controls are not persistently visible, so there is benefit to providing a - mechanism that allows users to have the controls persistently visible. -

- - -

Many scenarios are out of scope because they do not rely on hover or focus, for example:

- -
    - -
  • Options/fields become visible because of a selection elsewhere on the form. For example, address and City fields only appearing once the - user has selected a State. -
  • - -
  • An e-reader that allows the user to select a text passage and then pops-up a contextual toolbar with buttons that allows the - user to interact with that text. -
  • - -
  • Controls that become visible upon scrolling, such as a confirmation button that only - appears when the user has scrolled through all the content in a Terms and Conditions - dialog. -
  • - -
- - -
-
-
-

Benefits

- -
-
-

Examples

- -
-
Note
-

Other Success Criteria apply to the requirement for controls being “visible." Visibility - is not limited to appearing graphically on the screen, but also includes following - a meaningful sequence, not relying on sensory characteristics, and all other requirements - under 1.4: Distinguishable. -

-
-
-
-

Techniques

-

Each numbered item in this section represents a technique or combination of techniques - that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, - it is not necessary to use these particular techniques. For information on using other - techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. -

-
-

Sufficient Techniques

-
    - -
  1. - G222: Provide persistently visible controls - -
  2. - - - -
  3. Indicate programmatically that a control is important (future)
  4. - -
-
-
-
-

Key Terms

-
essential
-
- - - -

if removed, would fundamentally change the information or functionality of the content, - and information and functionality cannot be achieved in another way that would conform - -

- - -
-
-
user interface component
-
- - - -

a part of the content that is perceived by users as a single control for a distinct - function - -

- - -
-
Note
-

Multiple user interface components may be implemented as a single programmatic element. - "Components" here is not tied to programming techniques, but rather to what the user - perceives as separate controls. - -

-
- - -
-
Note
-

User interface components include form elements and links as well as components generated - by scripts. - -

-
- - -
-
Note
-

What is meant by "component" or "user interface component" here is also sometimes - called "user interface element". - -

-
- - -

An applet has a "control" that can be used to move through content by line or page - or random access. Since each of these would need to have a name and be settable independently, - they would each be a "user interface component." - -

- - -
-
-
-
- - \ No newline at end of file