WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
Site Navigation: W3C Home > WAI Home > UAWG Home
This is a working document from the User Agent Accessibility Guidelines Working Group (UAWG) that details action taken on the @@ issues received from @@ commenters on the Last Call working drafts of 7 November 2013 of UAAG 2.0 and Implementing UAAG 2.0. The table includes relevent text from UAAG 2.0 and Implementing UAAG 2.0; the classification of the comment, the UAWG response, and whether the commenter agreed with the change. There may also be highlighted text in the Response column whether or not the change has been accepted into the latest Editors' Draft.
See also:
UAAG 2.0 Last Call Working Draft of 7 November 2013
Implementing UAAG 2.0 Working Draft of 7 November 2013
| Priority | Whole Line | Comments | Response | Disposition | type | Acknowledgment |
|---|---|---|---|---|---|---|
| General Comments | CR01: Chrome has a general philosophy that users should not be presented with too many settings or switches to control. Settings that are only enabled by a small minority of users increase the perceived complexity for everyone else and also increase the number of possible configurations for the developer to support and test. We prefer many such features to be available via extensions or add-ons instead. This document contains a large number of recommendations for additional configurations a user can specify, presumably via a specific option or setting built-into the browser. What do you think about having extensions available for each of these features, rather than building them into the browser? Would Chrome be considered compliant with this spec if we implemented all of these guidelines as extensions and published an easy-to-use catalog of these for users to browse and install the ones they want? The "Implementing" spec even references Firefox add-ons, like Text Equivalent Expand Abbreviations. Do the spec authors feel that such features should be built into the browser, or merely that such an option must be available to users? |
|||||
| General Comments | CR03: Some of the recommendations seem overly technical and narrow: for example, the use-case for Show Element Hierarchy is that a user might want to write a custom stylesheet and needs to determine the path to a particular element within a page to write a style rule for it. However, there are already more innovative solutions to this problem available. A popular Chrome extension, StyleBot, lets the user simply click on any element on the page and modify the custom stylesheet with a friendly dialog interface. They can explore the classes that this element belongs to and apply the same style change to all elements in that class. My concern is just that these guidelines should not specify one narrow solution to a problem that precludes a more clever implementation. | |||||
| General Comments | CR04: Many of the guidelines are specific to a desktop computer, and written in a way that's too narrow to apply to a web browser running on a phone, tablet, or other device that may not have a keyboard. The guidelines should be written in a way that explain the user need and don't assume that a keyboard is available. | |||||
| General Comments | CR05: Many of the guidelines suggest features that are already available in existing assistive technology - for example opening an elements list, navigation by headings, or using voice control to jump to an element. Do the guidelines really mean to suggest that the browser should reimplement these as browser features rather than making them features of the AT? It's not clear to me that browsers should be providing these features directly - rather, they should expose rich information to AT via accessibility APIs, and allow AT to innovate ways to present this information to diverse groups of users. | |||||
| AP01: I think most of the UAAG can already be achieved in most browsers with a combination of user style sheets and user scripts. | ||||||
UAAG 2.0 Conformance Applicability Notes |
||||||
| Recognized Content Only UAAG 2.0 success criteria only apply to web content and its behaviors that can be recognized by user agents. | ||||||
| Optional Settings: Throughout UAAG 2.0, all required behaviors may be provided as optional preference settings unless a success criterion explicitly says otherwise. For example, if a success criteria requires high contrast between foreground text and its background, the user agent may also provide choices with low contrast. A required behavior does not need to be the default option unless the success criteria explicitly says otherwise. | ||||||
| RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language (must, may, should) because these are guidelines and not interoperable specifications. These words in UAAG 2.0 don't have the same sense as they do in RFC 2119. | ||||||
| Simultaneous satisfaction of success criteria: Users can access all behaviors required by UAAG 2.0 at the same time (e.g. when the user resizes the viewport per 1.8.9, content is reflowed per 1.8.6), except where those behaviors are mutually exclusive. | ||||||
PRINCIPLE 1- Ensure that the user interface and rendered content are perceivable |
||||||
Guideline 1.1 - Provide access to alternative content |
||||||
| Summary: The user can choose to render any type of alternative content available. (1.1.1). The user can also choose at least one alternative such as alt text to be always displayed (1.1.3), but it's recommended that users also be able to specify a cascade (1.1.5), such as alt text if it's there, otherwise longdesc, otherwise filename, etc. It's recommended that the user can configure the caption text and that text or sign language alternative cannot obscure the video or the controls (1.1.4). The user can configure the size and position of media alternatives (1.1.6). | ||||||
| A | 1.1.1 Render Alternative Content: The user can choose to render any type of recognized alternative content that is present for a content element. (Level A) Note: It is recommended that the user agent allow the user to choose whether the alternative content replaces or supplements the original content element. |
|||||
| A | 1.1.2 Indicate Unrendered Alternative Content: The user can specify that indicators be displayed along with rendered content when recognized unrendered alternative content is present. (Level A) | |||||
| A | 1.1.3 Replace Non-Text Content: The user can request a placeholder that incorporates recognized text alternative content instead of recognized non-text content, until explicit user request to render the non-text content. (Level A) | |||||
| AA | 1.1.4 Provide Configurable Alternative Content Defaults: The user can specify which type(s) of alternative content to render by default for each type of non-text content, including time based media. (Level AA) | |||||
| AA | 1.1.5 Facilitate Clear 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)
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. |
|||||
| AAA | 1.1.6 Allow Resize and Reposition 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)
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. |
|||||
Guideline 1.2 - Repair missing content |
||||||
| Summary: The user can request useful alternative content when the author fails to provide it. For example, showing metadata in place of missing or empty (1.2.1) alt text. The user can ask the browser to predict missing structural information, such as field labels, table headings or section headings (1.2.2). | ||||||
| AA | 1.2.1 Support Repair by Assistive Technologies: If text alternatives for non-text content are missing or empty then both of the following are true: (Level AA)
|
|||||
| AAA | 1.2.2 Repair Missing Structure: The user can specify whether or not the user agent should attempt to insert the following types of structural markup on the basis of author-specified presentation attributes (e.g. position and appearance): (Level AAA)
|
|||||
Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links |
||||||
| Summary: The user can visually distinguish selected, focused, and enabled items, and recently visited links (1.3.1), with a choice of highlighting options that at least include foreground and background colors, and border color and thickness (1.3.2). | ||||||
| A | 1.3.1 Highlighted Items: The user can specify that the following classes be highlighted so that each is uniquely distinguished: (Level A) | |||||
| A | * Selection | |||||
| A | * Active keyboard focus (indicated by focus cursors and/or text cursors) | |||||
| A | * Recognized enabled input elements (distinguished from disabled elements) | |||||
| A | * Recently visited links | |||||
| AA | 1.3.2 Highlighting Options: When highlighting classes specified by 1.3.1 Highlighted Items, the user can specify highlighting options that include at least: (Level AA) | |||||
| AA | * Foreground colors | |||||
| AA | * Background colors | |||||
| AA | * Borders (color, style, and thickness) | |||||
| AA | * Size when the indicator is an image | |||||
| AA | * Blink rate (where implemented) | |||||
Guideline 1.4 - Provide text configuration |
CR02: Settings that allow the user too much control over the layout and formatting invariably cause some web pages to be unusable. As an example, the minimum font size setting can be great for accessibility. However, it can make many websites with more complicated layouts unusable because the relatives sizes of text vs other elements on the page can now be off by a substantial margin. In contrast, most browsers now support a "zoom" feature that magnifies all elements on the page proportionally. To a web author, this is equivalent to the user modifying the width of the window, a case that already needs to be handled gracefully. I don't feel that we should be telling users that they can't use a website because the web author is making the text too small, or using a font that's inaccessible to them. However, it's also counterproductive to give the user so much control that too many sites become impossible to use, and web developers will have no incentive or ability to fix their sites since there are so many permutations they need to support. For example, I worry that the ability to change line spacing, character spacing, or justification might create more compatibility problems than they solve accessibility problems. I don't have any objection to allowing the user to specify font subsitutions, in comparison. |
|||||
| Summary: The user can set text scale, color, and font family globally (1.4.1, Level A); set text size, color, and font family for element types (1.4.2, Level AA); set line spacing, character spacing, word spacing, text style, and justification globally (1.4.3, Level AA); set text style, margins, and borders for elements (1.4.5, Level AAA); set line spacing, capitalization, hyphenation, margins, and borders globally (1.4.6, Level AAA); and print configured and reflowed text (1.4.4 Level AA). | ||||||
| Note 1: Success criteria 1.4.1, 1.4.3, and 1.4.6 address configuration at a global level, that is, it changes all of the text. Success criteria 1.4.2 and 1.4.5 are at an element type level, such as configuring just the heading text. | ||||||
| Note 2: All of the success criteria under guideline 1.4 allow users to override the text characteristics specified by authors, and override user agent defaults. | ||||||
| Note 3: The success criteria in guideline 1.4 can be met through user stylesheets. For platforms without user stylesheets, text configuration needs to be provide to users through the user agent's main user interface. | ||||||
| A | 1.4.1 Text Scale, Color, Font (Globally): The user can globally set all of the following characteristics of visually rendered text content: (Level A) | |||||
| A | * Text scale with preserved size distinctions (e.g. keeping headings proportional to main font) | |||||
| A | * Text color and background color, choosing from all platform color options | |||||
| A | * Font family, choosing from all platform fonts | |||||
| AA | 1.4.2 Text Size, Color and Font (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings and input fields:(Level AA) | WD01:
1.4.2: Problem: Users also need to style hyper links at the element. Solution: Add: "...at least heading input fields and links." |
Change SC as recommended |
Accepted |
Substantive |
|
| AA | * Text size | |||||
| AA | * Text color and background color, choosing from all platform color options | |||||
| AA | * Font family, choosing from all platform fonts | |||||
| AA | 1.4.3 Text Spacing and Style (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text:(Level AA) | WD02:
1.4.3: Problem: the lengths for character spacing and word spacing appear to be absolutes. This would be wrong. Solution: Add a note. (so you will have Note 1 (as is) and a new Note 2) "
Note 2: The lengths for character and word spacing are interpreted the same as letter and word spacing CSS 2 and up. The length value is added to the default character and word spacing for the font. |
||||
| 1.4.3 Text Spacing and Style (Globally): | SB05: 1.4.3 and 1.4.6 BOTH mention "line spacing" - does it really need to be listed twice? With different settings ranges? or maybe I've misunderstood (which means others might misunderstand). | |||||
| AA | * Line spacing of at least 1.0, 1.3, 1.5, and 2.0 times the font height | |||||
| AA | * Character spacing of at least 0.01, 0.03, 0.06, 0.09 times the base character width | |||||
| AA | * Word spacing of at least 0.01, 0.03, 0.06, 0.09 times the base character width | |||||
| AA | * Text style (underline, italic, bold) | |||||
| AA | * Justification (left, right, or full) | |||||
| Note: For the purposes of UAAG 2.0, the base character width is the font width of the character commonly accepted as the base character for calculating kerning in the typography for that language (e.g. zero character in English). | ||||||
| AA | 1.4.4 Configured and Reflowed Text Printing: The user can print any rendered visual, non-time-based content to the user's choice of available printing devices. (Level AA) | |||||
| Note: The user must be able to print content as it is rendered on screen, reflecting user scaling, highlighting, and other modifications, but reflowable content is reflowed for the print margins. | ||||||
| AAA | 1.4.5 Text Style, Margins, Borders (by Element): The user can set all of the following characteristics of visually rendered text content for main text and for text element types including at least headings and input fields: (Level AAA) | |||||
| AAA | * Text style (underline, italic, bold) | |||||
| AAA | * Margins (for example, space above headings, indentation of lists) | |||||
| AAA | * Borders | |||||
| AAA | 1.4.6 Spacing, Capitalization and Hyphenation (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AAA) | |||||
| AAA | * Line spacing between 0.7 and 3.0 times the font height, at increments of 0.10 | |||||
| AAA | * Capitalization (overriding upper case and small caps style) | |||||
| AAA | * Word-breaking properties (auto-hyphenation) | |||||
| AAA | * Margins | |||||
| AAA | * Borders | |||||
| Note: This success criteria does not apply to text entered as all caps. Content authors are encouraged to use styles instead of typing text as all caps. | ||||||
| Guideline 1.5 - Provide volume configuration | ||||||
| Summary: The user can adjust the volume of each audio track relative to the global volume level (1.5.1). | ||||||
| A | 1.5.1 Global Volume: The user can adjust the volume of each audio tracks independently of other tracks, relative to the global volume level set through operating environment mechanisms. (Level A) | |||||
| Guideline 1.6 - Provide synthesized speech configuration | ||||||
| Summary: If synthesized speech is produced, the user can specify speech rate, volume, and voice (1.6.1, Level A), pitch and pitch range (1.6.2, Level AA), advanced synthesizer speech characteristics such as emphasis (1.6.3, Level AAA) and features such as spelling (1.6.4, Level AAA). | ||||||
| A | 1.6.1 Speech Rate, Volume, and Voice: If synthesized speech is produced, the user can specify the following: (Level A) | |||||
| A | * Speech rate | |||||
| A | * Speech volume (independently of other sources of audio) | |||||
| A | * Voice, when more than one voice is available | |||||
| AA | 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) | |||||
| AA | * Pitch (average frequency of the speaking voice) | |||||
| AA | * Pitch range (variation in average frequency) | |||||
| Note: Because the technical implementations of text to speech engines vary (e.g. formant-based synthesis, concatenative synthesis), a specific engine may not support varying pitch or pitch range. A user agent should expose the availability of pitch and pitch range control if the currently selected or installed text to speech engine offers this capability. | ||||||
| AAA | 1.6.3 Advanced Speech Characteristics: The user can adjust all of the speech characteristics provided by the speech synthesizer. (Level AAA) | |||||
| AA | 1.6.4 Synthesized Speech Features: If synthesized speech is produced, the following features are provided: (Level AA) | |||||
| AA | * User-defined extensions to the synthesized speech dictionary. | |||||
| AA | * "Spell-out": text is spelled one character at a time, or according to language-dependent pronunciation rules. | |||||
| AA | * At least two ways of speaking numerals: spoken as individual digits and punctuation (e.g. "one two zero three point five" for 1203.5 or "one comma two zero three point five" for 1,203.5), and spoken as full numbers are spoken (e.g. "one thousand, two hundred and three point five" for 1203.5). | |||||
| AA | * At least two ways of speaking punctuation: spoken literally, and with punctuation understood from speech characteristics like pauses. | |||||
| AA | 1.6.5 Synthesized Speech Language: If synthesized speech is produced and more than one language is available, the user can change the language. (Level AA) | |||||
| Guideline 1.7 - Enable configuration of user stylesheets | ||||||
| Summary: The user agent supports user stylesheets (1.7.1, Level A), the user can choose which if any user-supplied (1.7.2, Level A) and author-supplied (1.7.3, Level A) stylesheets to use, and the user can save stylesheets (1.7.4, Level AA). | ||||||
| A | 1.7.1 Support User Stylesheets: If the user agent supports a mechanism for author stylesheets, the user agent also provides a mechanism for user stylesheets. (Level A) | |||||
| A | 1.7.2 Apply User Stylesheets: If user stylesheets are supported, then the user can enable or disable user stylesheets for: (Level A) | |||||
| A | * All pages on specified websites, or | |||||
| A | * All pages | |||||
| A | 1.7.3 Disable Author Stylesheets: If the user agent supports a mechanism for author stylesheets, the user can disable the use of author stylesheets on the current page. (Level A) | |||||
| AA | 1.7.4 Save Copies of Stylesheets: The user can save copies of the stylesheets referenced by the current page. This allows the user to edit and load the copies as user stylesheets. (Level AA) | SB01: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed. |
SB01: The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. It should be noted that many browsers already implement this success criteria. |
|||
| Guideline 1.8 - Help users to orient within, and control, windows and viewports | ||||||
| Summary: The user agent provides programmatic and visual cues to keep the user oriented. These include highlighting the viewport (1.8.1, Level A) and customizing the highlighting attributes (1.8.8, Level AA), keeping the focus within the viewport (1.8.2 & 1.8.6, Level A), resizing the viewport (1.8.9, Level A), providing scrollbars that identify when content is outside the visible region (1.8.3, Level A) and which portion is visible (1.8.4, Level A), changing the size of graphical content with zoom (1.8.5, Level A & 1.8.7, Level A), and restoring the focus and point of regard when the user returns to a previously viewed page (1.8.10, Level AA). The user can specify that all viewports have the same user interface elements (1.8.13, Level AA), if and how new viewports open (1.8.11, Level AA), and whether the new viewport automatically gets focus (1.8.12, Level AA). The user can mark items in a webpage and use shortcuts to navigate back to marked items. (1.8.14, Level AAA). | ||||||
| A | 1.8.1 Highlight Viewport: The user can have the viewport with the input focus be highlighted. (Level A) | |||||
| A | 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) | |||||
| A | 1.8.3 Provide 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) | |||||
| A | 1.8.4 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level A) | |||||
| A | 1.8.5 Allow Zoom: The user can rescale content within top-level graphical viewports as follows: (Level A) | |||||
| A | * Zoom in: to 500% or more of the default size | |||||
| A | * Zoom out: to 10% or less of the default size, so the content fits within the height or width of the viewport | |||||
| A | 1.8.6 Maintain Point of Regard: 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) | |||||
| A | 1.8.7 Reflow Text: The user can specify that text content in a graphical top-level viewport reflows so the text forms a single column that fits within the width of the viewport. (Level A) Note 1: Reflow applies even when text is rescaled or zoomed. Note 2: For vertical layout languages (e.g. Mongolian, Han), text should fit within the height of the viewport, rather than its width, to reduce vertical scrolling |
SB02: 1.8.7 (Reflow Text) - I think there's a possible
misunderstanding here with the wording "text content in a
graphical top-level viewport". Some developer might think "oh,
if it's only about text in a top-level viewport, then it doesn't
apply to text in a table (or other layout device) within that
viewport", which is not ideal especially if such layout device
is being used unnecessarily. Maybe add something like "This
applies even if such text is included within other structures"? |
||||
| AA | 1.8.8 Customize Viewport Highlighting: When highlighting viewports as specified by 1.8.1 Highlight Viewport, the user can customize attributes of the viewport highlighting mechanism (e.g. blink rate for blinking, color and width of borders). (Level AA) | |||||
| AA | 1.8.9 Allow Viewport Resize: The user can resize viewports within restrictions imposed by the platform, overriding any values specified by the author. (Level AA) | |||||
| AA | 1.8.10 Provide Viewport History: For user that implement a history mechanism for top-level viewports (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) | |||||
| AA | 1.8.11 Allow Top-Level Viewport Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA) | SB03: Re 1.8.11 (Allow Top-Level Viewport Open on Request) it might also be worth explicitly stating that, if the user performs some action whose normal meaning is "open link in new tab" (for example, middle-click on some browsers) then it should be possible for users to specify that such actions must ALWAYS perform that meaning, and cannot be overridden by the page author. Some Javascript "onClick" events manage to (accidentally) override middle-clicks and cause something to happen on the current page instead of opening a new tab. (In many cases this can be worked around by right-clicking on the link and selecting "open in new tab", instead of middle-clicking, but that can be extra effort and it's an annoyance.) | ||||
| AA | 1.8.12 Allow Top-Level Viewport Focus Control: 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) | |||||
| AA | 1.8.13 Allow Same User Interface: The user can specify that all top-level viewports (e.g. windows or tabs) follow the defined user interface configuration. (Level AA) | |||||
| AAA | 1.8.14 Provide 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) | |||||
| Guideline 1.9 - Provide alternative views | ||||||
| Summary: The user can view the source of content (1.9.2, Level AAA), and an outline view of important elements. (1.9.1, Level AA). | ||||||
| AA | 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. | ||||||
| AAA | 1.9.2 Source View: The user can view all source text that is available to the user agent. (Level AAA) | |||||
| Guideline 1.10 - Provide element information | ||||||
| Summary: The user can access information about relationships between elements (e.g. form labels, table headers) (1.10.1, Level AA), and extended link information (e.g. title, internal vs. external) (1.10.2, Level AAA) | ||||||
| AA | 1.10.1 Show Related Elements: The user can access related elements based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA) | |||||
| AAA | 1.10.2 Show Element Hierarchy: The user can determine the path of element nodes going from the root element of the element hierarchy to the currently focused or selected element. (Level AAA) | |||||
| PRINCIPLE 2. Ensure that the user interface is operable | ||||||
| Note: Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. If every potential user task is made accessible via modality independent controls that any input technology can access, a user can use what works best. For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. See Independent User Interface: Events for additional information on APIs and techniques for modality independent controls. | ||||||
| Guideline 2.1 - Ensure full keyboard access | ||||||
| Summary: Every viewport has a keyboard focus (2.1.2, Level A). Users can operate all functions using just the keyboard (2.1.1, Level A), activate important or common features with shortcut keys, (2.1.6, Level A), escape keyboard traps (2.1.3, Level A), specify that selecting an item in a dropdown list or menu not activate that item (2.1.4, Level A) and use standard keys for its platform (2.1.5, Level A). | ||||||
| A | 2.1.1 Provide Full Keyboard Functionality: 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) | |||||
| A | 2.1.2 Show Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times. (Level A) | |||||
| A | 2.1.3 Avoid Keyboard Traps: If keyboard focus can be moved to a component using a keyboard interface (including nested user agents), then focus can be moved away from that component using only a keyboard interface. If this requires more than unmodified arrow or Tab keys (or standard exit methods like Escape), users are advised of the method for moving focus away. (Level A) | |||||
| A | 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-supplied content. (Level A) | |||||
| A | 2.1.5 Follow Text Keyboard Conventions: The user agent follows keyboard conventions for the operating environment. (Level A) | |||||
| A | 2.1.6 Make Keyboard Access Efficient: The user agent user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level A) | |||||
| Guideline 2.2 - Provide sequential navigation | ||||||
| Summary: Users can use the keyboard to navigate sequentially to all the operable elements in the viewport (2.2.1, Level A) as well as between viewports (2.2.2, Level A), and the default navigation order is document order (2.2.3, Level A). Users can optionally disable wrapping or request a signal when wrapping occurs (2.2.4, Level AA). | ||||||
| A | 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) | |||||
| A | 2.2.2 Sequential Navigation Between Viewports: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A) | |||||
| A | 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) | |||||
| AA | 2.2.4 Options for Wrapping in Navigation: The user can request notification when sequential navigation wraps at the beginning or end of a document, and can prevent such wrapping. (Level AA) | |||||
| Guideline 2.3 - Provide direct navigation and activation | ||||||
| Summary: Users can navigate directly (e.g. using keyboard shortcuts) to important elements (2.3.1, Level AA) with the option of immediate activation of the operable elements (2.3.3, Level A). Display commands with the elements to make it easier for users to discover the commands (2.3.2 & 2.3.4, Level AA). The user can remap and save direct commands (2.3.5, Level AA). | ||||||
| AA | 2.3.1 Allow Direct Navigation to Important Elements: The user can navigate directly to important elements in rendered content. (Level AA) | |||||
| AA | 2.3.2 Present Direct Commands from Rendered Content: 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) | |||||
| A | 2.3.3 Allow Direct Activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A) | |||||
| AA | 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) | |||||
| AA | 2.3.5 Allow Customized Keyboard Commands: The user can remap 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). (Level AA) | |||||
| Guideline 2.4 - Provide text search | ||||||
| Summary: Users can search rendered content (2.4.1, Level A) forward or backward (2.4.2, Level A) and can have the matched content highlighted in the viewport (2.4.3, Level A). The user is notified if there is no match (2.4.4, Level A). Users can also search by case and for text within alternative content (2.4.5, Level AA). | ||||||
| A | 2.4.1 Text Search: The user can perform a search within rendered content, including rendered text alternatives and rendered generated content, for any sequence of printing characters from the document character set. (Level A) | |||||
| A | 2.4.2 Search Direction: The user can search forward or backward in rendered content. (Level A) | |||||
| A | 2.4.3 Match Found: When a search operation produces a match, the matched content is highlighted, the viewport is scrolled if necessary so that the matched content is within its visible area, and the user can search from the location of the match. (Level A) | |||||
| A | 2.4.4 Alert on Wrap or No Match: The user can choose to receive notification when there is no match to a search operation. The user can choose to receive notification when the search continues from the beginning or end of content. (Level A) | |||||
| AA | 2.4.5 Alternative Content Search: The user can perform text searches within alternative content that is text (e.g. text alternatives for non-text content, captions) even when the alternative content is not rendered onscreen. (Level AA) | |||||
| Guideline 2.5 - Provide structural navigation | ||||||
| Summary: Users can view (2.5.1, Level AA), navigate (2.5.2, Level A), and configure the elements used in navigating (2.5.3, Level AAA) content hierarchy. | ||||||
| AA | 2.5.1 Show Location in Hierarchy: When the user agent is presenting hierarchical information, but the hierarchy is not reflected in a standardized fashion in the DOM or platform accessibility services, the user can view the path of nodes leading from the root of the hierarchy to a specified element. (Level AA) | |||||
| AA | 2.5.2 Provide Navigation by Heading and within Tables: The user agent provides at least the following types of structural navigation, where the structure types exist: (Level AA) | |||||
| AA | * By heading | |||||
| AA | * Within tables | |||||
| AAA | 2.5.3 Allow Elements to be Configured for Structural Navigation: The user can configure a set of important elements (including element type) for structured navigation and hierarchical/outline view. (Level AAA) | |||||
| Guideline 2.6 - Provide access to event handlers | ||||||
| Summary: Users can interact with web content by mouse, keyboard, voice input, gesture, or a combination of input methods. Users can discover what event handlers (e.g. onmouseover) are available at each element and activate an element's events individually (2.6.1). | ||||||
| AA | 2.6.1 Allow Access and Activation of Input Methods: The user agent provides a means for the user to determine recognized input methods explicitly associated with an element, and a means for the user to activate those methods in a modality independent manner. (Level AA) | SB03: Re 2.6 - I think there definitely needs to be some easily-accessible switch to temporarily STOP all event handlers, then start them again later. Some websites have badly-implemented scripts that try to do fancy things as you move the mouse over elements, and these play badly with user stylesheets. For example, eBay's feedback mechanism can go horribly wrong at very large zoom levels. You move the mouse over the "5 star" rating, but as you do so, it adds an extra element into the text, causing the whole thing to reflow (the designers weren't expecting it to reflow - they didn't think it might be zoomed), and the reflow takes the star somewhere else so it is no longer under the mouse pointer, and this causes another event, undoing the first event, but then the star is again under the pointer, and so on ... result is a rapidly-flickering control, and less than 50/50 chance of it being activated when you click. Only workaround is to zoom out or increase the window size, but I wish I had a button that says "stop all event handlers until my next click" (bonus points if the user agent can AUTOMATICALLY detect the "rapid-fire" situation and turn them off until the next click). | ||||
| 2.6.1 Allow Access and Activation of Input Methods | CR06: Guideline 2.6 suggests that "users can discover what event handlers (e.g. onmouseover) are available at each element". This is impossible to implement - it's quite commonplace for a web author to install a global event listener, or an event listener on a container element, and decide what to do depending on the target element of each event that bubbles up. | |||||
| 2.6.1 Allow Access and Activation of Input Methods | AP02: In the specific case of this one: 2.6.1 Allow Access and Activation of Input Methods: I'm hopeful this one will be solved by IndieUI Events. | |||||
| Guideline 2.7 - Configure and store preference settings | ||||||
| Summary: Users can restore preference settings to default (2.7.2, Level A), and accessibility settings persist between sessions (2.7.1, Level A). Users can manage multiple sets of preference settings (2.7.3, Level AA), and adjust preference setting outside the user interface so the current user interface does not prevent access (2.7.4, Level AA), and transport settings to compatible systems (2.7.5, Level AA). | ||||||
| A | 2.7.1 Allow Persistent Accessibility Settings: User agent accessibility preference settings persist between sessions. (Level A) | |||||
| A | 2.7.2 Allow Restore All to Default: The user can restore all preference settings to default values. (Level A) | |||||
| AA | 2.7.3 Allow Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA) | |||||
| AAA | 2.7.4 Allow Preference Changes from 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 AAA) | |||||
| AAA | 2.7.5 Make Preference Settings Transferable: The user can transfer all compatible user agent preference settings between devices. (Level AAA) | |||||
| Guideline 2.8 - Customize display of graphical controls | ||||||
| Summary: It's recommended that users can add, remove, reposition, and assign shortcuts to user agent controls, and restore them to their default settings (2.8.1, Level AA). | ||||||
| AA | 2.8.1 Customize Display of Controls for User Interface Commands, Functions, and Extensions: The user can customize which user agent commands, functions, and extensions are displayed within the user agent user interface as follows: (Level AA) | |||||
| AA | * 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. | |||||
| AA | * Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some controls). | |||||
| AA | * 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). | |||||
| AA | * Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls. | |||||
| AA | * Reset: The user has the option to reset the containers and controls to their default configuration. | |||||
| Guideline 2.9 - Allow time-independent interaction | ||||||
| Summary: Users can extend the time limits for user input when such limits are controllable by the user agent (2.9.1, Level A). | ||||||
| A | 2.9.1 Adjustable Time Limits: Where time limits for user input are recognized and controllable by the user agent, the user can extend the time limits. (Level A) | SB04: Re 2.9.1 (Adjustable Time Limits) "the user can extend the time limits", would it be a good idea to add "indefinitely"? Just in case some developer thinks "just let them have a 50% extension". | ||||
| Guideline 2.10 - Help users avoid flashing that could cause seizures | ||||||
| Summary: To help users avoid seizures, the default configuration prevents the browser user interface and rendered content from flashing more than three times a second above luminescence or color thresholds (2.10.1, Level A), or even below the thresholds (2.10.2, Level AAA). | ||||||
| A | 2.10.1 Three Flashes or Below Threshold: In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period, unless the flash is below general flash and red flash thresholds. (Level A) | |||||
| AAA | 2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period (regardless of whether not the flash is below the general flash and red flash thresholds). (Level AAA) | |||||
| Guideline 2.11 - Provide control of time-based media | ||||||
| Summary: The user can present placeholders for time-based media (2.11.1, Level A) and executable regions (2.11.2, Level A), or block all executable content (2.11.3, Level A), adjust playback (2.11.4, Level A), stop/pause/resume (2.11.5, Level A), navigate by time (2.11.6, Level A) or semantic structures such as chapter (2.1.7, Level AA), enable or disable tracks (2.11.8, Level AA), and adjust contrast and brightness of visual time-based media (2.11.9, Level AAA). | ||||||
| A | 2.11.1 Time-Based Media Load-Only: The user can override the play on load of recognized time-based media content such that the content is not played until explicit user request. (Level A) | |||||
| A | 2.11.2 Execution Placeholder: The user can request 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) | |||||
| A | 2.11.3 Execution Toggle: The user can turn on/off the execution of dynamic or executable content (e.g. Javascript, canvas, media). (Level A) | |||||
| AA | 2.11.4 Adjustable Playback Rate for Prerecorded Content: The user can adjust the playback rate of prerecorded time-based media content, such that all of the following are true: (Level AA) | |||||
| AA | * Playback Rate: The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time. | |||||
| AA | * Pitch: Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality. | |||||
| AA | * Synchronization: Audio and video tracks remain synchronized across this required range of playback rates. | |||||
| AA | * Reset: The user agent provides a function that resets the playback rate to normal (100%). | |||||
| A | 2.11.5 Stop/Pause/Resume Time-Based Media: The user can stop, pause, and resume rendered audio and animation content (e.g video, animation, changing text) that lasts three or more seconds at the default playback rate. (Level A) | |||||
| A | 2.11.6 Navigation of Time-Based media by Time: If time-based media lasts three or more seconds at the default playback rate, the user can navigate it using a continuous scale and by relative time units. (Level A) | |||||
| AA | 2.11.7 Navigation of Time-Based Media by Semantics: The user can navigate by semantic structure within the time-based media, such as by chapters or scenes present in the media. (Level AA) | |||||
| AAA | 2.11.8 Video Contrast and Brightness: Users can adjust the contrast and brightness of visual time-based media. (Level AAA) | |||||
| Guideline 2.12 - Support other input devices | ||||||
| Summary: User agents support all of the platform's text input devices (2.12.1, Level A), and for all input devices the user can input text (2.12.3, Level AAA) and perform all other functions (2.12.2, Level AA). | ||||||
| A | 2.12.1 Platform Text Input Devices: If the platform supports text input using an input device, the user agent is compatible with this functionality. (Level A) | |||||
| AA | 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) | |||||
| AAA | 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) | |||||
| PRINCIPLE 3: Ensure that the user interface is understandable | ||||||
| Guideline 3.1 - Help users avoid unnecessary messages | ||||||
| Summary: Users can turn off non-essential messages from the author or user-agent (3.1.1, Level AA). | ||||||
| AA | 3.1.1 Reduce Interruptions: The user can avoid or defer: (Level AA) | |||||
| (a) Recognized messages that are non-essential or low priority | ||||||
| (b) Information in the user agent user interface that is being updated or changing | ||||||
| (c) Rendered content that is being updated or changing | ||||||
| Guideline 3.2 - Help users avoid and correct mistakes | ||||||
| Summary: Users can have form submissions require confirmation (3.2.1, Level AA), go back after navigating (3.2.2, Level AA), have their text checked for spelling errors (3.2.3, Level AA), undo text entry (3.2.4, Level A), avoid or undo settings changes (3.2.5, Level A), and receive indications of progress activity (3.2.6, Level A). | ||||||
| AA | 3.2.1 Form Submission Confirm: The user can specify whether or not recognized form submissions must be confirmed. (Level AA) | |||||
| AA | 3.2.2 Back Button: The user can reverse recognized navigation between web addresses (e.g. standard "back button" functionality). (Level AA) | |||||
| AA | 3.2.3 Spell Check: User agents provide spell checking functionality for text created inside the user agent. (Level AA) | |||||
| A | 3.2.4 Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) | |||||
| Note: Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer. | ||||||
| A | 3.2.5 Settings Changes can be Reversed or Confirmed: 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) | |||||
| A | 3.2.6 Retrieval Progress: By default, the user agent shows the state of content retrieval activity. (Level A) | |||||
| Guideline 3.3 - Document the user agent user interface including accessibility features | ||||||
| Summary: User documentation is available in an accessible format (3.3.1, Level A), it includes accessibility features (3.3.2, Level A), delineates differences between versions (3.3.3, Level AA), provides a centralized view of conformance UAAG2.0 (3.3.4, Level AAA). | ||||||
| A | 3.3.1 Accessible Documentation: Product documentation is available in a format that meets success criteria of WCAG 2.0 level "A" or greater. (Level A) | |||||
| A | 3.3.2 Describe Accessibility Features: For each user agent feature that is used to meet UAAG 2.0, at least one of the following is true: (Level A) | |||||
| (a) Described in the Documentation: Use of the feature is explained in the user agent's documentation; or | ||||||
| (b) Described in the Interface: Use of the feature is explained in the user agent user interface; or | ||||||
| (c) Platform Service: The feature is a service provided by an underlying platform; or | ||||||
| (d) Not Used by Users: The feature is not used directly by users (e.g., passing information to a platform accessibility service). | ||||||
| AA | 3.3.3 Changes Between Versions: Changes to features that meet UAAG 2.0 success criteria since the previous user agent release are documented. (Level AA) | |||||
| AAA | 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) | |||||
| Guideline 3.4 - Make the user agent behave in predictable ways | ||||||
| Summary: Users can prevent non-requested focus changes (3.4.1, Level A). | ||||||
| A | 3.4.1 Avoid Unpredictable Focus: The user can prevent focus changes that are not a result of explicit user request. (Level A) | |||||
| PRINCIPLE 4: Facilitate programmatic access | ||||||
| Guideline 4.1 - Facilitate programmatic access to assistive technology | ||||||
| Summary: The user agent supports platform accessibility services (4.1.1, Level A) that are quick and responsive (4.1.7, Level A), including providing information about all controls and operation (4.1.2, Level A & 4.1.6, Level AA), access to DOMs (4.1.4, Level A). Controls can be adjusted programmatically (4.1.5, Level A). Where something can't be made accessible, provide an accessible alternative version, such as a standard window in place of a customized window (4.1.3, Level A). | ||||||
| Note: UAAG 2.0 assumes that a platform accessibility API will be built on top of underlying security architectures that will allow user agents to comply with both the success criteria and security needs. | ||||||
| A | 4.1.1 Support Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A) | |||||
| A | 4.1.2 Expose Basic Properties: For all user interface components, including user agent user interface, rendered content, and generated content, the user agent makes available the following via a platform accessibility service: (Level A) | |||||
| A | * Name | |||||
| A | * Role | |||||
| A | * State | |||||
| A | * Value | |||||
| A | * Selection | |||||
| A | * Focus | |||||
| A | 4.1.3 Provide Equivalent Accessible Alternatives: 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) | |||||
| A | 4.1.4 Make DOMs Programmatically Available: If the user agent implements one or more Document Object Models (DOM), they must be made programmatically available to assistive technologies. (Level A) | |||||
| A | 4.1.5 Make Write Access Programmatically Available: If the user can modify the state or value of a piece of content through the user interface (e.g. by checking a box or editing a text area), the same degree of write access is programmatically available. (Level A) | |||||
| AA | 4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (Level AA) | |||||
| AA | * Bounding dimensions and coordinates | |||||
| AA | * Font family of text | |||||
| AA | * Font size of text | |||||
| AA | * Foreground and background color for text | |||||
| AA | * Change state/value notifications | |||||
| AA | * Highlighting | |||||
| AA | * Keyboard commands | |||||
| A | 4.1.7 Make Programmatic Exchanges Timely: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A) | |||||
| PRINCIPLE 5: Comply with applicable specifications and conventions | ||||||
| Guideline 5.1 - Comply with applicable specifications and conventions | ||||||
| Summary: When the browser's controls are authored in HTML or similar standards, they need to meet W3C's Web Content Accessibility Guidelines (5.1.1, Levels A, AA, AAA). The user agent supports the accessibility features of content formats (5.1.2, Level A) and of the platform (5.1.3, Level A), allows handling of unrendered technologies (5.1.4, Level A) including by alternative viewers (5.1.5, Level AA), and allows users to report accessibility issues (5.1.6, Level AAA). | ||||||
| A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria | 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria) | |||||
| Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). | ||||||
| A | 5.1.2 Implement Accessibility Features of Content Specifications: Implement the accessibility features of content specifications. Accessibility features are those that are either (Level A): * Identified as such in the content specifications or | |||||
| A | * Allow authors to satisfy a requirement of WCAG 2.0 | |||||
| Note 1: If a conformance claim is filed, cite the implemented specifications in the conformance claim. | ||||||
| Note 2: When a rendering requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. | ||||||
| A | 5.1.3 Implement Accessibility Features of the 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) | |||||
| Note: When a requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. | ||||||
| AA | 5.1.5 Allow Content Elements to be Rendered in Alternative Viewers: The user can select content elements and have them rendered in alternative viewers. (Level AA) | |||||
| AAA | 5.1.6 Enable Reporting of User Agent Accessibility Faults: The user agent provides a mechanism for users to report user agent accessibility issues. (Level AAA) |
Skip to Content 