diff --git a/understanding/21/animation-from-interactions.html b/understanding/21/animation-from-interactions.html index 4f92d73997..d7ea2b1425 100644 --- a/understanding/21/animation-from-interactions.html +++ b/understanding/21/animation-from-interactions.html @@ -27,21 +27,20 @@

Intent

The impact of animation on people with vestibular disorders can be quite severe. Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover.

-

How can a website reduce the chances of triggering a vestibular disorder? Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user agent or operating system.

- -

What about movement caused by a user scrolling a page? Moving new content into the viewport is essential for scrolling. The user controls the essential scrolling movement so it is allowed. Only add non-essential animation to the scrolling interaction in a responsible way. Always give users the ability to turn off unnecessary movement.

- -
-

Benefits

- -
+

How can a website reduce the chances of triggering a vestibular disorder? Choose any one of the following solutions. Avoid using unnecessary animation. Provide a control for users to turn off non-essential animations from user interaction. Take advantage of the reduce motion feature in the user agent or operating system.

+ +

What about movement caused by a user scrolling a page? Moving new content into the viewport is essential for scrolling. The user controls the essential scrolling movement so it is allowed. Only add non-essential animation to the scrolling interaction in a responsible way. Always give users the ability to turn off unnecessary movement.

+ +
+

Benefits

+

Examples

diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 8cbc3a5c30..9d737f25df 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -19,28 +19,26 @@

In brief

Intent

-

The intent of this Success Criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, they can be inappropriate and frustrating for speech input users whose dictation is interpreted as strings of letters, and for keyboard users who are prone to accidentally hit keys. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys.

-
-

Even though this Success Criterion refers to character keys, note that it's not relevant whether a shortcut can be activated using a single physical key on a keyboard, or if it requires a combination of keys to be pressed. For instance, on most full-size US and UK keyboard, the ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. The specific key combination required for certain characters will also vary depending on the user's keyboard layout. However, shortcuts that use these characters still fall under the requirements of this Success Criterion. What matters is that a shortcut relies on a printable character (letters, punctuation, numbers, symbol characters), and not the number of physical keyboard keys that users need to press to trigger it.

-
-
-

The Success Criterion also applies to situations where a shortcut is based on a sequence of character keys – for example, pressing G and then A in quick succession to trigger an action. While the individual character key presses don't immediately trigger the action, overall these types of shortcuts still rely on a series of character keys.

-
-

This success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. Accesskeys are also not affected because they are generally (depending on the user agent) activated using modifier keys.

-

Background on the mechanics of speech input

-

Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could decrease command efficiency significantly if users were to change to command mode and back before and after issuing each command.

-

Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.

-

Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

-

For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate (k), archive (y) and mute messages (m). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.

-

A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.

-
-

Benefits

-
    -
  • Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.
  • -
  • Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.
  • -
  • Allowing all shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.
  • -
-
+ +

The intent of this Success Criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hit keys. +To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys. +

+

Note that this success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. Accesskeys are also not affected because they include modifier keys.

+

Background on the mechanics of speech input:

+

Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could decrease command efficiency significantly if users were to change to command mode and back before and after issuing each command.

+

Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.

+

Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

+

For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.

+

A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.

+
+
+

Benefits

+ +

Examples

diff --git a/understanding/21/concurrent-input-mechanisms.html b/understanding/21/concurrent-input-mechanisms.html index 302c9f6534..eae3199d8e 100644 --- a/understanding/21/concurrent-input-mechanisms.html +++ b/understanding/21/concurrent-input-mechanisms.html @@ -26,7 +26,7 @@

Intent

Note: A touch-typing web application, which teaches users how to touch-type on a keyboard and/or measures their proficiency and speed, would be an example of an essential limitation to a particular input mechanism.

-

Benefits

+

Benefits

- \ No newline at end of file + diff --git a/understanding/21/label-in-name.html b/understanding/21/label-in-name.html index 8f6b4d649c..83569a2eea 100644 --- a/understanding/21/label-in-name.html +++ b/understanding/21/label-in-name.html @@ -90,19 +90,6 @@

Text in parentheses

It is important to mention parenthetical text in labels in the context of accessible name versus description. In common usage, text in parentheses is considered secondary but relevant to meaning. Users of speech recognition would not typically announce text in parentheses as part of the input name. For that reason, parenthetical text may be optionally considered a description and left out of the accessible name.

However, where parenthetical information provides important context, such as indication of a required field or limitations on what is allowed for input, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names. However, in order to pass 1.3.1 Info & Relationships, authors would need to programmatically surface both the required state and the limit on the allowed data formatting (in this example, eight integers fitting the YYYY-MM-DD pattern). The "required" state could be surfaced through the HTML required attribute or by using aria-required="true". The allowed data formatting could be surfaced by being referenced using the aria-describedby) attribute.

- - -
-

Benefits

- - -

Such textual information may constitute part of the component's description. So from both a programmatic viewpoint, and from the conservative tactic of only considering a label to be "adjacent text," neither headings, instructions, nor group 'labels' should normally be considered labels for the purpose of this Success Criterion.

-

It is important to note that the specification allows authors to override the name calculated through native semantics. Both aria-label and aria-labelledby take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, aria-label should be avoided or used carefully, and aria-labelledby should be used as a supplement with care.

-

Finally, aria-describedby is not included in the Accessible Name computation (instead it is part of the Accessible Description computation). By convention, text associated with a control through aria-describedby is announced immediately after the accessible name by screen readers. Therefore, the context of headings, instructions, and group labels can be provided through the accessible description to assist users of screen readers without affecting the experience of those who navigate using speech recognition software.

-
diff --git a/understanding/21/motion-actuation.html b/understanding/21/motion-actuation.html index 6eef73291f..17bc240c0a 100644 --- a/understanding/21/motion-actuation.html +++ b/understanding/21/motion-actuation.html @@ -28,16 +28,13 @@

Intent of this Success Criterion

Devices often have sensors that can act as inputs, such as accelerometer and gyroscope sensors on a phone or tablet device. These sensors can allow the user to control something by simply changing the orientation or moving the device in particular ways. In other situations, web content can interpret user gestures via the camera or other sensors to actuate functions. For example, shaking the device might issue an "Undo" command, or a gentle hand wave might be used to move forward or backward in a sequence of pages. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments. Therefore, functionality offered through motion must also be available by another mechanism.

In addition, some users may accidentally activate sensors due to tremors or other motor impairments. The user must have the ability to turn off motion actuation to prevent such accidental triggering of functions. Applications may be able to meet this requirement by supporting operating system settings which allow the user to disable motion detection at the system level.

There is an exception where motion is essential for the function or not using motions or gestures would invalidate the activity. Some applications are specifically created to use device sensor data. Examples of content that are exempt from this requirement include a pedometer that relies on device motion to count steps.

- - -
-

Benefits

- - -
+
+
+

Benefits

+

Examples of Success Criterion 2.6.1

diff --git a/understanding/21/orientation.html b/understanding/21/orientation.html index fe4698bc46..33f6c2b967 100644 --- a/understanding/21/orientation.html +++ b/understanding/21/orientation.html @@ -42,14 +42,13 @@

Locking a device to an orientation

This Success Criterion complements device "lock orientation" settings. A web page that does not restrict its display orientation will always support the system-level orientation setting, since the system setting is picked up by the user agent. Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).

The exception for things considered essential is aimed at situations where the content would only be understood in a particular orientation, or where the technology restricts the possible orientations. If content is aimed at a specific environment which is only available in one orientation (such as a television) then the content can restrict the orientation. Technologies such as virtual reality use screens within goggles that cannot change orientation relative to the user's eyes.

- -
-

Benefits

- -
+
+
+

Benefits

+

Examples

diff --git a/understanding/21/pointer-cancellation.html b/understanding/21/pointer-cancellation.html index 15f71271ad..8c9dc4d27b 100644 --- a/understanding/21/pointer-cancellation.html +++ b/understanding/21/pointer-cancellation.html @@ -56,13 +56,13 @@

Down-Event

-
-

Benefits

- +
+

Benefits

+

Examples

diff --git a/understanding/21/pointer-gestures.html b/understanding/21/pointer-gestures.html index d25296ebcc..1d935f749d 100644 --- a/understanding/21/pointer-gestures.html +++ b/understanding/21/pointer-gestures.html @@ -73,15 +73,14 @@

Challenges for people with disabilities

An exception is made for functionality that is inherently and necessarily based on complex paths or multipoint gestures. For example, entering your signature may be inherently path-based (although acknowledging something or confirming your identity need not be).

This Success Criterion does not apply to gestures that involve dragging in any direction because only the start and end points matter in a dragging operation. However, such gestures do require fine motor control. Authors are encouraged to provide non-dragging methods, for instance, a drag and drop operation could also be achieved by selecting an item (with a tap or keyboard interaction) and then selecting its destination as a second step.

- -
-

Benefits

-
    -
  • Users who cannot (accurately) perform path-based pointer gestures - on a touchscreen, or with a mouse - will have alternative means for operating the content.

  • -
  • Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because they are operating the touchscreen with an alternative input such as a head pointer) will have a single-pointer alternative for operating the content.

  • -
  • Users who may not understand the custom gesture interaction intended by the author will be able to rely on simple, frequently used gestures to interact. This can be especially beneficial for users with cognitive or learning disabilities.

  • -
-
+
+
+

Benefits

+

Examples

diff --git a/understanding/21/reflow.html b/understanding/21/reflow.html index 9db1a2b7b1..a03d1f481f 100644 --- a/understanding/21/reflow.html +++ b/understanding/21/reflow.html @@ -71,7 +71,7 @@

Browsers on mobile operating systems

-

Benefits

+

Benefits

diff --git a/understanding/21/status-messages.html b/understanding/21/status-messages.html index 014e30b4d7..f202bbd64e 100644 --- a/understanding/21/status-messages.html +++ b/understanding/21/status-messages.html @@ -31,14 +31,13 @@

Intent of this Success Criterion

Information can be added to pages which does not meet the definition of a status message. For example, the list of results obtained from a search are not considered a status update and thus are not covered by this Success Criterion. However, brief text messages displayed about the completion or status of the search, such as "Searching...", "18 results returned" or "No results returned" would be status updates if they do not take focus. Examples of status messages are given in the section titled Status Message Examples below.

This Success Criterion specifically addresses scenarios where new content is added to the page without changing the user's context. Changes of context, by their nature, interrupt the user by taking focus. They are already surfaced by assistive technologies, and so have already met the goal to alert the user to new content. As such, messages that involve changes of context do not need to be considered and are not within the scope of this Success Criterion. Examples of scenarios that add new content by changing the context are given in the section titled Examples of Changes That Are Not Status Messages below.

- -
-

Benefits

+
+
+

Benefits

    -
  • When appropriate roles or properties are assigned to status messages, the new content is spoken by screen readers in such a way as to assist blind and low vision users. Most sighted users can observe text peripherally added to the viewport. Such content provides additional information without affecting the user's current point of regard. The ability of an assistive technology to announce such new important text content allows more users to benefit from an awareness of the information in an equivalent manner.
  • -
  • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities, such as the potential to be exploited by assistive technologies created for users with some cognitive disabilities. Where page authors elect to design additions to the screen which do not change the user's context (i.e., take focus), the information is arguably of less importance than something presented using a modal dialog, which must be acknowledged by the user. As such, depending on the user's preferences, an assistive technology may choose to delay, suppress, or transform such messages so a user is not unnecessarily interrupted; or conversely the assistive technology may highlight such messages where the user finds it optimal to do so.
  • -
-
+
  • When appropriate roles or properties are assigned to status messages, the new content is spoken by screen readers in such a way as to assist blind and low vision users. Most sighted users can observe text peripherally added to the viewport. Such content provides additional information without affecting the user's current point of regard. The ability of an assistive technology to announce such new important text content allows more users to benefit from an awareness of the information in an equivalent manner.
  • +
  • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities, such as the potential to be exploited by assistive technologies created for users with some cognitive disabilities. Where page authors elect to design additions to the screen which do not change the user's context (i.e., take focus), the information is arguably of less importance than something presented using a modal dialog, which must be acknowledged by the user. As such, depending on the user's preferences, an assistive technology may choose to delay, suppress, or transform such messages so a user is not unnecessarily interrupted; or conversely the assistive technology may highlight such messages where the user finds it optimal to do so.
  • +

    Examples of Success Criterion 3.2.6

    diff --git a/understanding/21/target-size-enhanced.html b/understanding/21/target-size-enhanced.html index 62f172fd39..4fe12313eb 100644 --- a/understanding/21/target-size-enhanced.html +++ b/understanding/21/target-size-enhanced.html @@ -40,7 +40,7 @@

    Intent

    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

    +

    Benefits

    - \ No newline at end of file +