Implementing UAAG 2.0

Mobile Accessibility Examples from Implementing UAAG 2.0

This page lists mobile examples from Implementing UAAG 2.0: A guide to understanding and implementing User Agent Accessibility Guidelines 2.0. It includes the guidelines, success critieria, and intent to provide context for the mobile examples. For background, see the UAAG Overview.

These examples show how web browsers that follow UAAG benefit people with disabilities using the Web on mobile devices.

Browser support is just one aspect of mobile accessibility. W3C WAI's broader work related to mobile accessibility is introduced in Mobile Accessibility.

PRINCIPLE 1 - Ensure that the user interface and rendered content are perceivable

Implementing Guideline 1.1 - Provide access to alternative content.

1.1.2 Replace Non-Text Content:

The user can have all recognized non-text content replaced by alternative content, placeholders, or both. (Level A)

Note: At level A, the user agent can specify that an alternative content or placeholder replace the non-text content. At level AA success criterion 1.1.3 requires that the user can specify one format or placeholder to be used. At level AAA success criterion 1.1.5 requires that the user can specify a cascade order of types of alternative content to be used.

  • Intent of Success Criterion 1.1.2:
    Users may wish to hide images for a number of different reasons. Some users with cognitive disabilities may wish to hide images in order to avoid those that would be severely distracting. Some users with visual disabilities may wish to hide images in order to avoid those that are painful (such as those with high contrast). Other users may wish to replace images with alternative content because they are unlikely to be able to visually discern, understand, or otherwise benefit from the images. Some users with impaired motion or dexterity may wish to replace images with smaller alternative content to reduce the amount of scrolling they have to do, while some users with attention deficit disorder may wish to do the same thing in order to keep as much information visible on the screen as possible.
  • Mobile Examples of Success Criterion 1.1.2:
    • [mobile] Ben has low vision and needs to use a very large font size to be able to read text. On his mobile device, enlarging the page makes any images so large that they use up too much screen space and require excessive scrolling. He sets a preference to render all images as text (if available) and to reflow the page so that the text flows smoothly with no space for the missing images.
    • [mobile] Betty is a low vision user and has difficulty reading text on her mobile device when it is displayed over a background image. Using her user-defined style sheet, she can disable all background images from being rendered in her browser.

1.1.3 Configurable Alternative Content Defaults:

For each type of non-text content, the user can specify a type of alternative content that, if present, will be rendered by default. (Level AA)

  • Intent of Success Criterion 1.1.3:
    Alternative content is wasted if the user agent doesn't render it for users who need it. Default alternative content is a global setting because it is an unreasonable burden for users to change the rendering options every time they visit a new page.
  • Mobile Examples of Success Criterion 1.1.3:
    • Ben has low vision and keeps his mobile phone browser "zoomed" so he can read the text. Because images can become pixelated when enlarged, he prefers the alternative text. In the mobile settings dialog box, he chooses to always display the alternative ("fallback") content for images and to reflow the page without a placeholder for the image. This saves screen space and reduces the amount of scrolling he has to do. .

1.1.4 Display of Alternative Content for Time-Based Media:

For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the following are all true: (Level AA)

  1. Don't obscure primary media: The user can specify that displaying time-based media alternatives doesn't obscure the primary time-based media; and
  2. Don't obscure controls: The user can specify that the displaying time-based media alternatives doesn't obscure recognized controls for the primary time-based media; and
  3. Use configurable text: The user can configure recognized text within time-based media alternatives (e.g. captions) in conformance with 1.4.1.

Note: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size to meet this requirement.

  • Intent of Success Criterion 1.1.4:
    Users who require or can benefit from alternative media tracks in video or audio may not find that the default or authored position and size of those tracks is usable. Enabling the user to move and scale any displayed alternate media tracks (e.g. captions) allows displayed content to be positioned and sized to meet the needs of the user.
  • Mobile Examples of Success Criterion 1.1.4:
    • [mobile] Jaime is deaf and prefers to always display captions on her mobile phone. She has set her global settings on the phone to turn on closed captions. All videos displayed on the phone will automatically display captions.
    • [mobile] Ben has low vision that becomes worse throughout the day as he becomes more tired. He keeps a floating control on his mobile phone that allows one touch access to his configuration so that he can change the font size. The floating control can be easily moved around the screen so it is not in the way of other controls, and it becomes translucent after it is idle for a few seconds.

 

1.1.5 Default Rendering of Alternative Content (Enhanced):

For each type of non-text content, the user can specify the cascade order in which to render different types of alternative content when preferred types are not present. (Level AAA)

  • Intent of Success Criterion 1.1.5:
    For a given piece of non-text content the author may provide one or more alternatives. For example, an image may have different versions based on resolution, 'alt text' (@alt) or a link to a long description (@longdesc). A video may have bandwidth alternatives, caption files in different languages, and audio descriptions in different languages. Users can choose which item(s) to render by default, and specify the order of the cascade of alternatives to be rendered if the author provided multiple alternatives.
  • Mobile Examples of Success Criterion 1.1.5:
    • [mobile] Ben has low vision and prefers to display the longer alternative content (@alt or @title) on his desktop browser where his display allows. When using his mobile device, Ben has configured his device to display the shortest alternative content available for non-text content.

1.1.6 Size and Position of Time-Based Media Alternatives:

The user can configure recognized alternative content for time-based media (e.g. captions, sign language video) as follows: (Level AAA)

  1. The user can resize alternative content for time-based media up to the size of the user agent's viewport.
  2. The user can reposition alternative content for time-based media to at least above, below, to the right, to the left, and overlapping the primary time-based media.

Note 1: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size or hidden to meet this requirement.

Note 2: Implementation may involve displaying alternative content for time-based media in a separate viewport, but this is not required.

  • Intent of Success Criterion 1.1.6:
    Users may want to reposition the alternative in close proximity to the most important portion of the main media to reduce the visual scanning distance between them. For example, if the video frequently includes on-screen text near the top of the video then the captions will be easier to read if they are located above the video.
  • Mobile Examples of Success Criterion 1.1.6:
    • [mobile] When Tom watches narrow-aspect video on a wide-aspect screen, he moves the window displaying sign language interpretation to the side, allowing the primary video to take up the entire height of the screen without the interpretation getting in the way.
    • [mobile] Raymond has one functioning hand. He positions captions so that they're not covered by the hand he's using to hold his tablet.
    • [mobile] When Tom watches narrow-aspect video on a wide-aspect screen or in landscape mode on his mobile device, he moves the window displaying sign language interpretation to the side, allowing the primary video to take up the entire height of the screen without the interpretation getting in the way.

Implementing Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.

1.3.1 Highlighted Items:

The user can specify that the following classes be highlighted so that each is uniquely distinguished: (Level A)

  1. selection
  2. active keyboard focus (indicated by focus cursors and/or text cursors)
  3. recognized enabled input elements (distinguished from disabled elements)
  4. elements with alternative content
  5. recently visited links
  • Intent of Success Criterion 1.3.1:
    Users need to be able to easily discover web content they can interact with. One effective way to do this is to highlight enabled elements and links (including recently visited links). Highlighted selection and content focus lets people who use keyboard, gesture and speech input know where they working. On some pages controls may be difficult to discern amid a large amount of other content, or may be styled so the controls are difficult to distinguish from other content. This can be particularly difficult for people with visual impairments, who may not be able to distinguish subtle visual differences. People with some cognitive impairments may have difficulty distinguishing between items with similar or non-standard appearance. Visually distinguishing these items reduces the amount of time or number of commands these groups require to examine a page.

    Note: In addition to these required categories, it is recommended that user agents also allow the user to highlight the active viewport, even when it is a frame or similar within the active window. This makes it much easier for the user to visually locate the active focus.
    Note: Platform conventions will dictate whether or not keyboard focus in an inactive viewport is visually indicated by an inactive cursor.
    Note: the definition of visited and unvisited links is up to the user agent. Visited links may be links visited during the current session or in the browser's history.
  • Mobile Examples of Success Criterion 1.3.1:
    • [mobile] George has limited hand use and uses custom gestures on his mobile phone. He wants a visible focus indicator to know what element on the page has focus so when gestures are used on the mobile phone, he will know what element will be activated.
    • [mobile] Brin is deaf. The video player she is using has a button displayed beneath the playing video that indicates that captions are available. She clicks the button to toggle the captions on so she can understand the video. On her mobile phone, Brin touches a video, which displays the controls including the "display caption" control.

 

Implementing Guideline 1.4 - Provide text configuration.

1.4.1 Configure Rendered Text:

The user can globally set any or all of the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults: (Level A)

  1. text scale (the general size of text)
  2. font family
  3. text color (foreground and background)
  4. line spacing
  5. character spacing
  • Intent of Success Criterion 1.4.1:
    Users need to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their needs. In providing preferences, it is important to avoid making assumptions. For example, some users may increase font size to make text more legible, while other users may reduce the font size to decrease the need to scroll the content.
  • Mobile Examples of Success Criterion 1.4.1:
    • [mobile] Lee has low vision from albinism and has difficulty with screen resolution and brightness. She uses a browser on her mobile phone that supports only 3 font sizes: small, medium, and large. Lee needs to use a font size of 16 pt, which is between the medium and large sizes. The mobile phone settings provide an option to override the 3 font sizes with the operating system font range, so that Lee can select the 16 pt font size she needs.
    • [mobile] Ben has low vision. In the mobile settings dialog box, he chooses to large text for font size. All applications on the mobile phone display text in large font.

Implementing Guideline 1.6 - Provide synthesized speech configuration.

1.6.1 Speech Rate, Volume, and Voice:

If synthesized speech is produced, the user can specify the following: (Level A)

  1. speech rate,
  2. speech volume (independently of other sources of audio), and
  3. voice, when more than one voice option is available

1.6.2 Speech Pitch and Range:

If synthesized speech is produced, the user can specify the following if offered by the speech synthesizer: (Level AA)

  1. pitch (average frequency of the speaking voice), and
  2. pitch range (variation in average frequency)

Note: Because the technical implementations of text to speech engines vary (e.g., formant-based synthesis or concatenative synthesis), a specific engine may not support varying pitch or pitch range. A user agent will expose the availability of pitch and pitch range control if the currently selected or installed text to speech engine offers this capability.

1.6.3 Advanced Speech Characteristics:

The user can adjust all of the speech characteristics offered by the speech synthesizer. (Level AAA)

  • Intent of Success Criterion 1.6.1, 1.6.2, 1.6.3:
    These success criteria allow users to control speech characteristics so they can perceive and understand the audio information.

    For example, a user may need to increase the volume to a level within the user's range of perception. Or a user may increase the rate of synthesized speech presentation because the user understands it at a rate faster than the default setting of the user agent.

    Success criterion 1.6.1 covers characteristics that users most commonly need to adjust and that are adjustable in most technologies. Success criterion 1.6.2 covers characteristics that are less widely altered and less widely supported.
  • Mobile Examples of Success Criterion 1.6.1, 1.6.2, 1.6.3:
    • [mobile] Jamie is blind. He uses a mobile-based web browser to read a web page. He presses a key to increase the rate at which the information is read back. He also uses a mobile browser in a noisy environments such as a crowded subway. With a key press, Jamie quickly increases the volume.

 

Implementing Guideline 1.7 - Enable Configuration of User Stylesheets.

1.7.1 Support User Stylesheets:

If the user agent supports a mechanism for authors to supply stylesheets, the user agent also provides a mechanism for users to supply stylesheets. (Level A)

1.7.2 Apply User Stylesheets:

If user style sheets are supported, then the user can enable or disable user stylesheets for: (Level A)

  1. all pages on specified websites, or
  2. all pages

1.7.3 Author Style Sheets:

If the user agent supports a mechanism for authors to supply stylesheets, the user can disable the use of author style sheets on the current page. (Level A)

  • Intent of Success Criterion 1.7.1, 1.7.2 & 1.7.3:
    CSS stylesheets allow users and authors to customize the rendering of web content. Such customization is frequently used to make web content accessible to a wide range of user needs. These success criteria ensure that users can take full advantage of this ability to customize stylesheets. Since different websites may require different style changes to be readable, it is recommended that user agents provide a feature that lets the user specify which stylesheet should be automatically applied to different web pages as they are loaded (e.g. based on a list of domain names or URL templates).
  • Mobile Examples of Success Criterion 1.7.1, 1.7.2 & 1.7.3:
    • [mobile] Lee has low vision and finds text easiest to read text on her mobile device when it is presented in yellow on a black background. She has configured her browser to override the author stylesheets to always display text in her browser using this color scheme.
    • [mobile] Mattias has ADHD and finds text easiest to read text if text is highlighted in blue as it is being read out loud on his desktop or mobile device. Both the highlight and text color are configurable and override the author stylesheets so text is readable and has sufficient color contrast.

1.7.4 Save Copies of Stylesheets:

The user can save copies of the stylesheets referenced by the current page, in order to edit and load the copies as user stylesheets. (Level AA)

  • Intent of Success Criterion 1.7.4:
    Stylesheets provide for powerful customization of rendered content. Occasionally a user may need to make slight modifications to the author-supplied external stylesheets used on a website to satisfy certain accessibility needs. At other times a web author may have created a stylesheet that a user with a disability finds helpful. The intent of this success criteria is to allow users to easily save the CSS for a website and make needed modifications without having to create full stylesheet of their own and to apply well designed stylesheets to other web pages where they find the stylesheets helpful.
  • Mobile Examples of Success Criterion 1.7.4:
    • [mobile] Tanya has low vision. She browses to a new website on her mobile phone and finds that the site is not optimized for mobile devices. She alters the stylesheet to provide better layout and larger fonts. The custom settings for the stylesheet are saved and applied when she returns.

Implementing Guideline 1.8 - Help users to use and orient within windows and viewports.

1.8.2 Move Viewport to Selection and Focus:

When a viewport's selection or input focus changes, the viewport's content moves as necessary to ensure that the new selection or input focus location is at least partially in the visible portion of the viewport. (Level A)

  • Intent of Success Criterion 1.8.2:
    When content extends horizontally or vertically beyond the visible bounds of its viewport, users must be able to move to one or more selectable elements that may be out of view and to have the selected content automatically move into view. This gives keyboard users and screen magnification users an efficient means to view selected content without having to scroll to locate and view the selection.
  • Mobile Examples of Success Criterion 1.8.2:
    • [mobile] Lee typically views web content on her mobile phone at a high level of zoom, frequently positioning elements outside the viewport. When moving between focusable elements, the viewport automatically scrolls to the element currently in focus.

1.8.4 Viewport Scrollbars:

When the rendered content extends beyond the viewport dimensions, users can have graphical viewports include scrollbars, overriding any values specified by the author. (Level A)
  • Intent of Success Criterion 1.8.4:
    When rendered content exceeds the bounds of a graphical viewport, horizontal or vertical scrollbars show that not all of the rendered content is currently visible within the viewport and provide a means of navigation to that content. The scrollbars make it clear that the rendered content is not fully visible.
  • Mobile Examples of Success Criterion 1.8.4:
    • [mobile] Terry has memory issues. She configures her mobile computer so that scrollbars are always on so she can instantly see where she is in a document.

1.8.5 Indicate Viewport Position:

The user can determine the viewport's position relative to the full extent of the rendered content. (Level A)

  • Intent of Success Criterion 1.8.5:
    Users who have fine-motor problems that make it difficult to scroll, users who have cognitive issues that make it difficult to orient on the page, and screen reader users, who rely on audio to scan the page, all need to quickly assess the amount of content on the page and where they are located within the content.
  • Mobile Examples of Success Criterion 1.8.5:
    • [mobile] Ally has cognitive issues that make it difficult to orient. When looking at a map on her mobile device, she must frequently zoom in to view her current location or destination and zoom out to put the location into the context of the large map.

1.8.6: Zoom:

The user can rescale content within graphical viewports as follows: (Level A)

  1. Zoom in: to at least 500% of the default size; and
  2. Zoom out: to at least 10% of the default size, so the content fits within the height or width of the viewport.
  • Intent of Success Criterion 1.8.6:
    Some users want to be able to magnify content to so it is more legible. Some users  want to be able to shrink content so that more of it is visible onscreen. This can help them understand the structure of the content and their position in  the content, even if text has become too small to read.
  • Mobile Examples of Success Criterion 1.8.6:
    • [mobile] When Tanya views a web site on her mobile phone, she first scans the website at a very small size to guess where she wants to zoom in first. The zoom feature increases the size of both text and images.
    • [mobile] Ally has cognitive issues that make it difficult to orient. When looking at a map on her mobile device, she must frequently zoom in to view her current location or destination and zoom out to put the location into the context of the larger map.

1.8.7 Maintain point of regard:

To the extent possible, the point of regard remains visible and at the same location within the viewport when the viewport is resized, when content is zoomed or scaled, or when content formatting is changed. (Level A)

  • Intent of Success Criterion 1.8.7:
    Users can be confused and disoriented when the area where they are working suddenly shifts outside the visible region of the viewport. When this happens, users may have to expend considerable time and effort to re-navigate back to their previous point of regard. Just as the location in audio does not change when the user increases the volume, the point of regard should not change when the user changes the size of the window or zooms the content.

    The point of regard is the information within the viewport that is visible to the user. When there is focused or selected content inside a viewport, and the viewport is resized, or content is zoomed, scaled, or formatted differently, that content will remain visible in the viewport. Otherwise, the user agent should maintain the same top-left (top-right for text read right-to-left) corner as the initial viewport.

    Note: User agents are encouraged to allow user to override author instructions not to wrap content (e.g., nowrap).
  • Mobile Examples of Success Criterion 1.8.7:
    • [mobile] Xu has a reading disability. He is reading a page with footnotes that are too small to read on his mobile device. Xu places the footnote at the top of the browser, and using the increase font-size feature, he increases the font-size of the text on the page. The footnotes stay on the top of the viewport.

1.8.8 Viewport History:

For user agents that implement a viewport history mechanism (e.g. "back" button), the user can return to any state in the viewport history that is allowed by the content, including a restored point of regard, input focus and selection. (Level AA)

1.8.9 Open on Request:

The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA)

1.8.10 Do Not Take Focus:

If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open. (Level AA)

  • Intent of Success Criteria 1.8.8, 1.8.9 & 1.8.10:
    Unexpected focus and viewport changes can be disorienting for all users, requiring time and effort for the user to orient to the change. These success criteria are intended to allow the user to be in control of when viewport changes happen so the user can orient to the changes in a predictable fashion.
  • Mobile Examples of Success Criteria 1.8.8, 1.8.9 & 1.8.10:
    • [mobile] Ray is blind. His mobile device automatically opens location links and calendar dates found on web pages in native apps available on the device. When he returns to the browser, focus on the original link is maintained.

1.8.12 Reflowing Zoom:

The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA)

Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap).

  • Intent of Success Criterion 1.8.12:
    It's important that reflowed content remains easily usable. Content is not easily usable if the user has to scroll back and forth to see a single line of text. This is an especially acute issue for users who find it difficult or impossible to use the mouse to scroll and for users who find it difficult to reorient when the content changes. This does not require or prohibit the user agent from providing an option to turn off reflow.
  • Mobile Examples of Success Criterion 1.8.12:
    • [mobile] Frank has repetitive strain injuries and uses speech input. When Frank is using his mobile phone to read a web page, he will zoom in to read a article on a web site. He configures his mobile phone so that the text reflows to always display zoomed content to fit in one column.

1.8.13 Webpage Bookmarks:

The user can mark items in a webpage, then use shortcuts to navigate back to marked items. The user can specify whether a navigation mark disappears after a session, or is persistent across sessions. (Level AAA)

  • Intent of Success Criterion 1.8.13:
    This success criterion is crucial for users who have trouble navigating a webpage. People who use speech input, have memory problems, or use small screens may be able to go from one area of a webpage to another area once or twice, but may have trouble frequently repeating the action. The ability to mark areas of the page allows these types of users to navigate more quickly with less fatigue.
  • Mobile Examples of Success Criterion 1.8.13:
    • [mobile] Jamie is a quadriplegic who uses speech input. She is a professor who reads long documents online and often finds herself comparing different portions of the same document. It is tedious carrying out multiple scrolling commands by speech every time she needs to change to another portion of the document. She sets several bookmarks instead. This allows her to instantly jump among sections, eliminating the time and effort penalties she usually has to pay for slow scrolling. Jamie also uses bookmarks on her mobile phone to cut down on scrolling.
    • [mobile] George is blind and occasionally travels to unfamiliar places for work. He sometimes uses an iPhone to orient himself within a map of the building he's in. Once he's found a key place on the map – a room where a conference session is held, or the bathroom – he bookmarks it to build a map of useful places. This makes navigation easier the second time around. He sets the marks to be persistent across sessions so next time he visits he won't have to repeat his work.

Implementing Guideline 1.9 - Provide alternative views.

1.9.1 Outline View:

Users can view a navigable outline of rendered content composed of labels for important elements, and can move focus efficiently to these elements in the main viewport. (Level AA)

Note: The important elements depend on the web content technology, but may include headings, table captions, and content sections.

  • Intent of Success Criterion 1.9.1:
    Outline views allow users get a simplified view or overview of a document. They are particularly useful for users with memory or cognitive disabilities, blind users, and users who find it difficult or impossible to use a mouse. A navigable outline views reduce orientation and navigation time and fatigue.
  • Mobile Examples of Success Criterion 1.9.1:
    • [mobile] George uses a screen reader. He reads long standards documents and uses the headings to navigate quickly so he can compare sections of the standards. George also finds the outline view useful when he is quickly checking a reference on his mobile phone.

1.9.2 Source View:

The user can view all source text that is available to the user agent. (Level AAA)

  • Intent of Success Criterion 1.9.2:
    The source view is the ultimate fallback for a person with disabilities when the browser cannot properly render some content, or when the user cannot take advantage of the content as rendered or using the mechanisms provided.
  • Mobile Examples of Success Criterion 1.9.2:
    • [mobile] George uses a screenreader. He visits a web page where the content author failed to provide alt text or a long description for an image he wants to access. As a last resort, George examines the source to see the image's URI, class, and similar attributes. He sees that part of the URI for the image is "home.jpg" and concludes that he can click on that image to return to the home page of the site. George also uses the source view feature on his mobile device when he needs to identify an image.

PRINCIPLE 2. Ensure that the user interface is operable

Implementing Guideline 2.1 - Ensure full keyboard access.

2.1.1 Keyboard Operation:

All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A)

  • Intent of Success Criterion 2.1.1:
    A user has many ways to input information into a computer or device, including mouse, keyboard, gesture, and speech. The keyboard paradigm is the most universal interface for text input ndash; even devices that do not have a keyboard (like mobile phones) support a software interface for them. A user should be able to navigate, read and use all of the web page or application without needing to use a mouse. Some users do not use a mouse. Others can only use a pointing device that uses the keyboard API. It's important that these users be able to interact with enabled components, select content, navigate viewports, configure the user agent, access documentation, install the user agent, and operate user interface controls, all entirely through keyboard input.
    User agents generally support at least three types of keyboard operation:
    1. Direct (e.g. keyboard shortcuts such a "F1" to open the help menu; see checkpoint 11.4 for single-key access requirements)
    2. Sequential (e.g. navigation through cascading menus)
    3. Spatial (e.g. when the keyboard is used to move the pointing device in two-dimensional visual space to manipulate a bitmap image)

    User agents should support direct or sequential keyboard operation for all functionalities. The user agent should offer a combination of keyboard-operable user interface controls (e.g. keyboard operable print menus and settings) and direct keyboard shortcuts (e.g. to print the current page).
  • Mobile Examples of Success Criterion 2.1.1:
    • [mobile] Karen has muscular dystrophy and cannot easily use the onscreen keyboard to navigate Web pages on her mobile phone. Instead, she uses simple gestures to move between elements on the page. As focus moves from one element to another, there is a visble focus indicator.

2.1.2 Keyboard Focus:

Every viewport has an active or inactive keyboard focus at all times. (Level A)

  • Intent of Success Criterion 2.1.2:
    Both the user and some types of assistive technology need to know what will be affected by any keyboard input, so it's important that they be able to tell which window, viewport, and controls have the keyboard focus at any time. This applies whether window and viewport are active (active keyboard focus) or inactive (inactive keyboard focus). Even when a window is inactive, it can be affected by simulated keyboard input sent by assistive technology tools. Active keyboard focus is indicated to the user by focus cursors and text cursors, as required by Guidelines 1.3, and made available to assistive technology, as required by Success Criterion 4.1.6.
  • Mobile Examples of Success Criterion 2.1.2:
    • [mobile] Jeremy is a speech-input user who cannot use his hands to control his tablet. He opens a webpage using a speech command. The webpage has a search field, and normally comes up with the keyboard focus in the search field. Jeremy sees the indicator in the search field and knows he does not have to navigate to the search field before saying a search term.
    • [mobile] Erin has dyslexia which often causes her to confuse directions. She uses gestures to navigate her mobile phone. As focus moves from one element to another, there is a visble focus indicator, which allows her to find the focus easily.

 

2.1.4 Separate Selection from Activation:

The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author content. (Level A)

  • Intent of Success Criterion 2.1.4:
    People do not expect side effects when moving the keyboard focus regardless of whether the side effect is caused by the user agent or author content. If users fail to notice side effects, they could end up doing something disastrous. This is especially likely for users of assistive technology who cannot see changes happening elsewhere on the screen. Users may also find it confusing or disorienting if the effect causes unexpected focus movement or changes in context. If the user agent does implement side effects to keyboard navigation, it is recommended that it provide a user preference setting to disable them. However, in some cases it may be more appropriate to provide a separate navigation mechanism that avoids side effects, such as allowing the user to hold down the Ctrl key while navigating to avoid changing selection or choice. Note: It may not be possible for the user agent to detect or prevent side effects implemented by scripts in the content, but the user agent is required to prevent side effects that are under its control.
  • Mobile Examples of Success Criterion 2.1.4:
    • [mobile] Ari uses Voiceover on his iPhone to navigate a webpage. He selects an item and is able to activate the element using gestures. This requires sufficient screen real estate to perform gestures without changing focus.

 

2.1.6 Efficient Keyboard Access:

The user agent user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level A)

  • Intent of Success Criterion 2.1.6:
    Efficient keyboard navigation is especially important for people who cannot easily use a mouse, are quickly fatigued, or find it difficult to memorize the menu structure for sequential navigation. This is important in all types of user agent environments.
    • In a browser: A browser provides keyboard shortcuts for its menu functions as well as access keys in the design of its menus and dialog boxes. The choice of shortcut keys follows platform conventions where applicable (e.g. for open document, save document, cut, copy, paste).
    • In a mobile environment: A social networking application on a mobile device has only a very few keyboard shortcuts available on its targeted devices. These few keyboard shortcuts are used for the most commonly accessed functions of the application (e.g. home, list of friends).
    • In a media player: A embedded media player provides shortcut keys for commonly used functions (e.g. pause and play).
  • Mobile Examples of Success Criterion 2.1.6:
    • [mobile] George is blind and uses the gestures on his mobile device to move focus to the top of the page, return to the previous web page and activate links.

Implementing Guideline 2.2 - Provide sequential navigation

2.2.1 Sequential Navigation Between Elements :

The user can move the keyboard focus backwards and forwards through all recognized enabled elements in the current viewport. (Level A)

  • Intent of Success Criterion 2.2.1:
    Sequential keyboard navigation is a fundamental, universal method of keyboard access. While it can be slower and require more input than other methods (such as direct, structural, or search-based navigation) it is a simpler mechanism that requires very little cognitive load or memorization, and is consistent across contexts. Users need keyboard access to all viewports and all enabled elements so that they can manipulate them, view them with screen magnifiers, or have them described by screen readers. The ability to move both forward and backward through the navigation order greatly reduces the number of keystrokes and allows the user to more easily recover from mistakes in overshooting a destination.
  • Mobile Examples of Success Criterion 2.2.1:
    • [mobile] George is blind and uses a screenreader on his computer and the speech output and gesture features of his mobile phone. When completing a web form on his phone, he uses the swipe gesture to advance through the form. If George goes past the next form field, or wishes to return to a previous form field, he can use a gesture to go backward.

2.2.3 Default Navigation Order:

If the author has not specified a navigation order, the default sequential navigation order is the document order. (Level A)

  • Intent of Success Criterion 2.2.3:
    When the content author doesn't explicitly define a consistent tab order, the browser will provide one. Users need to have a mental map of where the focus will land when they press the Tab key or use other sequential navigation commands. If the focus jumps in seemingly random fashion, skipping up or down, it becomes impossible to use this method efficiently because users must stop, find the focus, reorient, and determine what direction they should proceed every time they press navigation keys. This is a particular problem for users with some cognitive limitations or whose disability makes input difficult, tiring, or painful. Content authors are expected to define a logical navigation order in their documents, but if they have not, this success criterion ensures that the order will at least be consistent between user agents.
  • Mobile Examples of Success Criterion 2.2.3:
    • [mobile] Alec is filling out an HTML form. Because the form's author has not specified a navigation order using the tabindex attribute, when Alec presses the Tab key the focus moves to the next control in the order defined in the underlying HTML. This order is logical as long as the author is not using styles to change the visual order. Alec has the same experience completing this form on his mobile phone.

2.2.4 Options for Wrapping in Navigation:

The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can request notification when such wrapping occurs. (Level AA)

  • Intent of Success Criterion 2.2.4:
    Users need a good mental map of the navigation sequence and behavior, and particularly need to know when they have started over again so they can maintain that mental map and not waste time and energy inadvertently revisiting information. This is a greater problem for users who have limited short-term memory, perceive a narrow field of vision, or use a screen magnifier, screen reader or small screen device. This also prevents people with mobility issues from having to use extra navigation commands.
  • Mobile Examples of Success Criterion 2.2.4:
    • [mobile] Jeff has a mobility impairment. He uses gestures to navigate the page. When he reaches the last active element on the page there is an indicator that the end of the page is reached before changing focus (e.g. wrapping to the top, switching pages).

Implementing Guideline 2.3 - Provide direct navigation and activation

2.3.1 Direct Navigation to Important Elements:

The user can navigate directly to any important elements (e.g. structural or operable) in rendered content. (Level AA)

  • Intent of Success Criterion 2.3.1:
    People who are blind or have mobility problems often find it difficult or impossible to use a mouse to move the viewport to, and focus on, important elements. Some other form of direct navigation – such as numbers or key combinations assigned to important elements – should be available. Direct navigation can be accessed via keyboard, which also supports other forms of input, such as gesture, speech and touch.
  • Mobile Examples of Success Criterion 2.3.1:
    • [mobile] Mary cannot use the mouse or keyboard due to a repetitive strain injury. She uses speech input with a mouseless browsing plug-in for her browser. She is able to use the same plug-in on her smartphone. The plug-in overlays each link with a number that can then be used to directly select it (e.g. by speaking the command "link 12"). This prevents Mary from having to say "tab" numerous times to select a link.

2.3.2 Present Direct Commands from Rendered Content (enhanced):

The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email). (Level AA)

  • Intent of Success Criterion 2.3.2:
    For many users, including those who use the keyboard or an input method such as speech, the keyboard is often a primary method of user agent control. It is important that direct keyboard commands assigned to user agent functionality be discoverable, including in rendered content. If direct commands are not presented in content, many users will not discover them.
  • Mobile Examples of Success Criterion 2.3.2:
    • [mobile] When reading email on her tablet, Mary touches a control which opens a toolbar with a setting to display the accesskeys and other direct commands that the author created. She sees that a 3-finger swipe will delete the current email.

2.3.3 Direct activation of Enabled Elements:

The user can move directly to and activate any enabled element in rendered content. (Level A)

  • Intent of Success Criterion 2.3.3:
    People who are blind or have mobility problems often find it difficult or impossible to use a mouse to move the viewport to, focus on, and activate important elements. Some other form of direct navigation – such as numbers or key combinations assigned to important elements – should be available. Direct navigation can be accessed via keyboard, which also supports other forms of input, such as gesture, speech and touch.
  • Mobile Examples of Success Criterion 2.3.3:
    • [mobile] Mary cannot use the mouse or keyboard due to a repetitive strain injury. On her mobile phone, Mary uses a single speech command to launch the app, rather than having to use multiple commands to page through screens to find the app icon and activate it.

2.3.4 Present Direct Commands in User Interface:

The user can have any direct commands in the user agent user interface (e.g. keyboard shortcuts) be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA)

  • Intent of Success Criterion 2.3.4:
    For many users, including those who use the keyboard or and input method such as speech, the keyboard is often a primary method of user agent control. It is important that direct keyboard commands assigned to user agent functionality be discoverable as the user is exploring the user agent. If direct commands are not presented in content, many users will not discover them.
  • Mobile Examples of Success Criterion 2.3.4:
    • [mobile] Neta has a repetitive strain injury. She relies on gestures and shortcuts to complete tasks. Using a specialized command on her mobile device, she can pull up an overlay of arrows and text showing all the commands that can be completed in that context. This allows her to learn new programs as efficiently as possible, making it less likely she will overtax her hands..

2.3.5 Customize Keyboard Commands:

The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. The user must be able to save these settings beyond the current session. (Level AA)

  • Intent of Success Criterion 2.3.5
    People using a keyboard interface need the ability to remap the user agent's keyboard shortcuts in order to avoid keystroke conflicts with assistive technology, reduce number of keystrokes, use familiar keystroke combinations, and optimize keyboard layout (e.g. for one-handed use). This is important for people with dexterity issues where every keystroke can be time consuming, tiring or painful. It is also important for people using assistive technologies such as screen readers, where many keystrokes are already in use by the assistive technology. The goal of this success criterion is to enable the user to be in control of what happens when a given key is pressed, use the keyboard commands that meet specific needs, and save the modifications.

    Content authors can use the Accesskey attribute to define shortcut keys that allow quick access to specific elements, actions, or parts of the Web content. The author can select shortcuts that are different from what the user expects. Users who rely upon keyboard input may want consistent shortcut keys across the sites they visit.

    Users should have the option to make any keyboard shortcuts be persistent across browsing sessions.

    User agents can also offer the user the option to automatically apply preferred key combinations for content that has author-specified accesskey bindings that are based on the associated text, label, or ARIA role. This overrides any author-specified keybinding.
  • Mobile Examples of Success Criterion 2.3.5:
    • [mobile] Laura types with one hand. On her mobile device, Laura maps common website actions to numeric shortcut keys. For example, she prefers to have the 1 key to activate a site's search function. An author of a site visited daily by this user defines "S" as the accesskey for the search function. Laura overrides the author-specified accesskey of "S" with "1".

Implementing Guideline 2.5 - Provide structural navigation.

 

2.5.2 Navigate by structural element:

The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA)

  1. by heading
  2. within tables
  • Intent of Success Criterion 2.5.2:
    Users who find it difficult or impossible to use the mouse require an efficient way to jump among elements without having to navigate through intervening content. Navigating by heading is especially important when scanning a webpage to find a pertinent section. Navigating by table element is especially important when building or reading tables.
  • Mobile Examples of Success Criterion 2.5.2:
    • [mobile] Armand is blind. When he uses the speech input to locate a web page on his smartphone, Armand navigates from heading to heading using touch commands.

2.5.3 Configure Elements for Structural Navigation:

The user can configure sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)

  • Intent of Success Criterion 2.5.3:
    Authors can visually convey relationships between elements by grouping them spatially, or giving them the same coloration or background. Users may not be able to perceive those attributes when using a screen reader, or when strong magnification makes it difficult to make a mental model of the screen layout. In cases like these, the user agent can assist by providing a view of the data that groups elements that that user agent perceives as implying relationships.

    Often the user agent will choose by default the elements it considers important for structured navigation. These may not be relevant in all circumstances. For example, the user may wish to navigate via informal mechanisms such as microformats or or by a particular element.
  • Mobile Examples of Success Criterion 2.5.3:
    • [mobile] When Fred is using his smartphone, he selects a control that allows him to change from navigation by heading to navigation by links.

Implementing Guideline 2.6 - Provide access to event handlers

2.6.1 Access to input methods:

The user can discover recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner. (Level AA)

  • Intent of Success Criterion 2.6.1:
    Users interacting with a web browser may use one or more input technologies including keyboard, mouse, speech, touch, and gesture. Sometimes a web page is scripted so that it assumes and requires an input method that is not available to the user, such as handling drag events for a user relying solely on the keyboard. In those cases, the user needs to determine what methods are available and activate that element with a modality independent method.

    In addition, any one input method should not hold back another. For instance, people who don't use a mouse shouldn't have to map their input methods to the same steps a mouse user would take. The user agent can constrain steps such as not allowing a mouseup before a mousedown.
  • Mobile Examples of Success Criterion 2.6.1:
    • [mobile] Ingrid has low vision. When navigating a page with a smartphone, she can chooose a bluetooth keyboard or gestures to operate all of the controls within the page.

Implementing Guideline 2.7 - Configure and store preference settings

2.7.1 Persistent Accessibility Settings:

User agent accessibility preference settings persist between sessions. (Level A)

  • Intent of Success Criterion 2.7.1:
    When a user has customized settings within the user agent to maximize accessibility, customization is saved between browsing sessions. The user can automatically use those settings in subsequent browsing sessions.
  • Mobile Examples of Success Criterion 2.7.1:
    • [mobile] Betty has low vision. She customizes her mobile browser's color and font settings to make text much easier to read. Her browser incorporates a cloud-based profile so she can retain her settings across her browsing sessions and her desktop and tablet browsers.

2.7.2 Restore all to default:

The user can restore all preference settings to default values. (Level A)

  • Intent of Success Criterion 2.7.2:
    For some users, it may be difficult to easily recall all modified settings. Others may find it difficult to navigate to each modified setting, especially if a particular setting impacts their ability to do so. Users who customize settings may find that their chosen settings are not suitable and decide to restore these settings to default values. This success criteria allows a user to easily restore all preference settings to default values using a single function or action.
  • Mobile Examples of Success Criterion 2.7.2:
    • [mobile] Kathy has repetive stress injuries which makes it painful to experiment with settings. She accidently turns on a zoom feature on her smartphone and cannot figure out how to turn it off. She gestures to navigate to the preferences menus and selects a command to reset preferences to default.

2.7.3 Multiple Sets of Preference Settings:

The user can save and retrieve multiple sets of user agent preference settings. (Level AA)

  • Intent of Success Criterion 2.7.3:
    Some users may need to change their setting preferences under circumstances such as varying levels of user fatigue, changes in environmental noise, or changing lighting conditions. Providing an easy method for saving and switching between sets of preferences helps the user complete intended tasks.
  • Mobile Examples of Success Criterion 2.7.3:
    • [mobile] Hiroki has low vision. When he is carrying his tablet computer he operates it with the built-in touchscreen. When at his desk he links it to a Bluetooth keyboard and mouse, and redirects the display to a large computer monitor. The browser allows him to quickly switch between different configurations for different environments.

2.7.4 Change preference settings outside the user interface:

The user can adjust any preference settings required to meet the User Agent Accessibility Guidelines (UAAG) 2.0 from outside the user agent user interface. (Level AA)

  • Intent of Success Criterion 2.7.4:
    Users with disabilities may not be able to use a user agent in a particular configuration. This can occur during setup when default settings don't meet their needs, or after someone changes an option. If users cannot change the settings from the user interface, they need a way to adjust or reset those options from outside the user agent. The user agent can accomplish this in multiple including including detecting and implementing the platform accessibility settings, providing an external file to modify, providing access to settings from a separate utility program, providing accessibility options in the installation program, or providing command-line switches to change the user agent's behavior.

    Note: User agents are encouraged to allow all user preferences to be adjusted.
  • Mobile Examples of Success Criterion 2.7.4:
    • [mobile] Jan is easily confused by new interfaces. Using the screen reader capabilities on her mobile phone she changes the interface of the updated browser, then can't figure out how to undo them. She uses an app from the browser developer to reset the browser settings to default.

2.7.5 Portable Preference Settings:

The user can transfer all compatible user agent preference settings between computers. (Level AAA)

  • Intent of Success Criterion 2.7.5:
    Configuring a user agent may be a complex and time-consuming task. Some users hire assistive technology professional trainers to do their system setup. Users who have spent time customizing accessibility preferences to meet their requirements need to migrate preference setting to other compatible devices. Schools and universities also need to maintain accessibility settings across multiple machines.
  • Mobile Examples of Success Criterion 2.7.5:
    • [mobile] Betty is a low vision user and has a highly customized color palette defined in her browser. She saves her customizations to a cloud-based storage service, so her preferences can be transferred to the other desktop and mobile browsers that she uses.

Implementing Guideline 2.8 - Customize display of GUI controls

2.8.1 Customize display of controls representing user interface commands, functions, and extensions:

The user can customize which user agent commands, functions, and extensions are displayed within the user agent's user interface as follows:(Level AA)

  1. Show: The user can choose to display any controls available within the user agent user interface, including user-installed extensions. It is acceptable to limit the total number of controls that are displayed onscreen.
  2. Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some control).
  3. Reposition: The user can choose to reposition individual controls within containers (e.g. Toolbars or tool palettes), as well as reposition the containers themselves to facilitate physical access (e.g. To minimize hand travel on touch screens, or to facilitate preferred hand access on handheld mobile devices).
  4. Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls.
  5. Reset: The user has the option to reset the containers and controls to their original configuration.
  • Intent of Success Criterion 2.8.1:
    The user needs to control which user interface elements are visible and usable, where elements are visually located on the screen, and where elements fall in the navigation order. In some cases adjusting whether an element is visible and usable may involve installing or uninstalling a component — or merely showingor hiding it — depending on the user agent and the specific component. This can reduce keystrokes, bring buttons into view that are hidden by default or otherwise allow the user to interact with the user agent in a more efficient fashion. Users with dexterity impairments or mobility impairments may have problems making the large movements required to select between non-adjacent controls which they need to use frequently. Similarly, users with low vision may have to move their magnified view-port excessively to see frequently used controls. Enabling these controls to be situated together removes some of the strain faced by these users, and increases productivity as task completion times are decreased.
  • Mobile Examples of Success Criterion 2.8.1:
    • [mobile] Laura has one hand. When she holds her mobile phone in her left hand, she must use her thumb to press the controls. She configures her mobile apps so that the toolbars are at the left side or the bottom, so she can reach them.
    • [mobile] Linda has rheumatoid arthritis and finds it difficult to perform the pinch gesture that's commonly used to zoom on mobile phones. She changes the default gesture for zooming to a gesture she can more easily do. Linda's left hand is less damaged than her right hand. She moves a common control from the right side of the screen to the left side of the screen to make it easier to access with her left hand.
    • [mobile] Jennifer is blind. She sometimes configures apps on her friend Linda's mobile phone. When Jennifer picks up Linda's mobile phone, she turns on the built-in voice application so she so she can quickly find her way around Linda's phone. When Jennifer is done, she changes the controls back to Linda's original settings..

 

Implementing Guideline 2.11 - Provide control of content that may reduce accessibility.

Applicability Notes:

Guideline 2.11 and its success criteria only apply to images, animations, video, audio, etc. that the user agent can recognize.

 

2.11.2 Execution Placeholder:

The user can render a placeholder instead of executable content that would normally be contained within an on-screen area (e.g. Applet, Flash), until explicit user request to execute. (Level A)

  • Intent of Success Criterion 2.11.2:
    Documents that do things automatically when loaded can delay, distract, or interfere with user's ability to continue with a task. Replacing executable content like embedded objects, applets and media with a placeholder tells the user what has been blocked and provides a mechanism (e.g. a play button) for unblocking when the user is ready.
  • Note: A placeholder should take up the same space as the object it is replacing, so that the presentation doesn't need to be reflowed when the execution is started. However, people using mobile devices or screen enlargers, or those who have difficulty with scroll commands may benefit from having the option of a smaller placholder.
  • Mobile Examples of Success Criterion 2.11.2:
    • [mobile] Evan has configured his mobile phone to so any audio or video file displays a placeholder with a triangle "play" icon. That allows him to control when the audio or video starts.

Implementing Guideline 2.12 - Other Input Devices

 

2.12.2 Operation With Any Device:

If an input device is supported by the platform, all user agent functionality other than text input can be operated using that device. (Level AA)

  • Intent of Success Criterion 2.12.2:
    Some users rely entirely on pointing devices, touch, or gestures, and find these methods more convenient than keyboards. Other users rely on speech input. These users can operate applications more easily and efficiently if they can navigate and control applications. On systems that support alternative input methods, it is important that the user agent support these utilities.
  • Mobile Examples of Success Criterion 2.12.2:
    • [mobile] Randall has repetitive stress injuries. The web browser on his smart phone allows him to perform most operations using speech commands. Unfortunately, a few features are only available through the touchscreen, which Randall finds painful to use. In the next version of the browser, the remaining features are enabled using speech, and Randall finds the product safer and more convenient to use.

2.12.3 Text Input With Any Device:

If an input device is supported by the platform, all user agent functionality including text input can be operated using that device. (Level AAA)

  • Intent of Success Criterion 2.12.3:
    If the platform does not support text, the user agent provides a mechanism for text input as well as all other input device controls. Some users rely entirely on pointing devices, or find them much more convenient than keyboards. These users can operate applications much more easily and efficiently if they can carry out most operations with the pointing device, and only fall back on a physical or on-screen keyboard as infrequently as possible. If the platform provides the ability to enter arbitrary text using a device (such as large vocabulary speech recognition or an on-screen keyboard utility), the user agent is required to support it per 2.12.1 Text Input With Any Device. If the platform does not provide such a feature, the browser is encouraged to provide its own.
  • Mobile Examples of Success Criterion 2.12.3:
    • [mobile] Randall has a web browser on his smart phone that allows him to perform most operations using speech commands. By offloading the speech recognition to an Internet server, it is able to perform large vocabulary speech recognition, so Randall can use his voice to compose email and fill in forms, as well as controlling the browser itself.

PRINCIPLE 3: Ensure that the user interface is understandable

Implementing Guideline 3.2 - Help users avoid and correct mistakes.

3.2.5 Settings Change Confirmation:

If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A)

  • Intent of Success Criterion 3.2.5:
    The description of some user interface settings can be confusing to less technical users. Settings changes can also have unintended consequences. In addition, some disabilities make it more likely that a user can make an unintended selection on a preference screen.  Users need to be able to reverse changes to the user interface.
  • Mobile Examples of Success Criterion 3.2.5:
    • [mobile] Davy has moderately low vision. He is adjusting the contrast of the background on his mobile phone when he accidentally selects a white background with the previously selected white text. This causes all the icon labels to disappear.  He can see a highlighted rectangle on the screen that usually contains the word "undo" when he makes a change on his phone. He selects that box and the dark background returns, so he can now read the text.  He then changes the background to a color with sufficient contrast for comfortable reading.

Implementing Guideline 3.3 - Document the user agent user interface including accessibility features.

3.3.2 Document Accessibility Features:

All features of the user agent that meet User Agent Accessibility Guidelines 2.0 success criteria are documented. (Level A)

  • Intent of Success Criterion 3.3.2:
    People that use the accessibility features of the user agent user interface need easy descriptions of how to use and configure the features. These descriptions can be provided in the documentation or user interface of the user agent or by the underlying platform, if the feature is a service of that platform.
  • Mobile Examples of Success Criterion 3.3.2:
    • [mobile] Neta has a repetitive strain injury. She relies on gestures and shortcuts to complete tasks. Using a specialized command, she pulls up a list of all the gesture commands available including descriptions.

3.3.4 Centralized View:

There is a dedicated section of the documentation that presents a view of all features of the user agent necessary to meet the requirements of User Agent Accessibility Guidelines 2.0. (Level AAA)

  • Intent of Success Criterion 3.3.4:
    Users need to know about accessibility features and how to operate them. A centralized view of accessibility features makes it easier for people with disabilities and people who are evaluating software to quickly become familiar with the features such as keyboard shortcuts, how to zoom the viewport, and where to find accessibility configuration settings. Nested user agents or addons may provide separate centralized documentation. It is also useful to document accessibility features in context (such as displaying keyboard shortcuts next to their menu command).
  • Mobile Examples of Success Criterion 3.3.4:
    • [mobile] Bob is blind and uses a screen reader that is part of his phone's operating system. He downloads a new web browser on his mobile phone. The browser's online help includes a section on accessiblity that point him to pages on non-visual access, such as interaction with screen readers, helpful hints such as an explanation of the screen layout, and a list of supported touch gestures.

PRINCIPLE 4: Facilitate programmatic access

Implementing Guideline 4.1 - Facilitate programmatic access to assistive technology

4.1.3 Accessible Alternative:

If a component of the user agent user interface cannot be exposed through platform accessibility services, then the user agent provides an equivalent alternative that is exposed through the platform accessibility service. (Level A)

  • Intent of Success Criterion 4.1.3:
    Like everyone else, users who rely on assistive technology need to be able to carry out all tasks provided by the user agent. When a particular user interface component cannot support the platform accessibility service, and thus can't be made compatible with assistive technology, the user agent should let the user achieve the same goal using another component that is fully accessible.
  • Mobile Examples of Success Criterion 4.1.3:
    • [mobile] Doug uses a mouse-stick on his smart phone. He uses the assistive touch option on his mobile phone to control an app for 3D design drawing. The app provides a single, complex control for 3-dimensional manipulation of a virtual object. This custom control cannot be represented in the platform accessibility service, so the app provides Doug the option to achieve the same functionality through an alternate user interface: a panel that adjusts the yar, spin, and roll independently using arrow keys.

PRINCIPLE 5: Comply with applicable specifications and conventions

Implementing Guideline 5.1 - Comply with applicable specifications and conventions.

 

5.1.3 Implement Accessibility Features of platform:

If the user agent contains non-web-based user interfaces, then those user interfaces follow user interface accessibility guidelines for the platform. (Level A)

  • Intent of Success Criterion 5.1.3:
    User agent user interfaces that are not web applications need to be accessible to people with disabilities. Accessibility guidelines already exist for many platforms. Most operating systems have conventions and expectations that aid accessibility, such as keyboard behavior, support of an accessibility API, user interface design. User agents need to comply with the basic accessibility requirements of the platform in use. Developers have the flexibility to conform with the appropriate accessibility guidelines or legislation for their platform or markets.

    The user should be able to easily discover detailed information about the user agent's adherence to accessibility standards, platform standards such as MSAA or JAA, and third-party standards such as ISO 9241-171, and should be able to do so without installing and testing the accessibility features.

    NOTE: In the conformance claim, list the requirements you fully comply with, list the requirements you partially comply with and explain, and list the requirements you do not comply with and explain. Where applicable, this explanations can be general and cover several sections at once.
  • Mobile Examples of Success Criterion 5.1.3:
    • [mobile] Martin uses a mouth stick to control his mobile browser. Even though he cannot use a pinch gesture, he controls the zoom in his mobile browser with a custom gesture. He can do this because the app developer followed the guidance provided in the "Accessibility Programming Guide for iPhone OS".