W3C logoWeb Accessibility initiative

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

Site Navigation: W3C Home > WAI Home > UAWG Home

Disposition of Comments:
UAAG 2.0 and UAAG 2.0 Reference
Working Drafts of 25 September 2014

Updated on:
24 October, 2014
This Version (Github)
http://jspellman.github.io/UAAG-LC-Comment/

This is a working document from the User Agent Accessibility Guidelines Working Group (UAWG) that details action taken on the 10 issues received from 3 commenters on the working drafts of 25 September 2014 of UAAG 2.0 and UAAG 2.0 Reference (formerly Implementing UAAG 2.0). Most of these comments are in response to the request to accept the changes made to previous comments on the UAAG 2.0 Last Call Working Draft.

The following table includes relevent text from 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. If there was extensive discussion in UAWG about the issue, the word "UAWG" in the response is linked to the minutes of that meeting.

See also:
UAAG 2.0 Last Call Working Draft of 7 November 2013
Implementing UAAG 2.0 Working Draft of 7 November 2013

Comments Received from:

Silas Brown (SB)- 3 comments
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0013.html
Lisa Seeman (CA - Cognitive Accessibility Task Force) - 1 comment
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0001.html
Cynthia Shelly (MS -Microsoft) - 6 comments
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html

Legend:

Disposition of Comments

Priority Whole Line Comments Response Disposition type Acknowledgment
  Introduction: Definition of User Agent MS01: Definition of "User agent" should not include "web-based user agent" We do not agree that a "web-based user agent" is a legitimate concept. If it's web-based, it's content. WCAG was written to cover web applications, including those that render content. UAAG should not be covering that. The target audience of this document should be user agent implementers, not end users. The fact that end users don't understand how it is engineered is not relevant.

 

  substantive  
  General: UAAG Reference  MS05: Examples in the implementation document do not make distinction of content, browser, assistive technologies, and OS We still feel that this area of UAAG is fundamentally flawed. UAAG needs to clarify what should be done in the browser, where the browser should rely on OS features, where it should go beyond them, and what should be done by AT. The target audience of this document should be user agent implementers, not end users. We don't believe it to be relevant that end users may not understand the engineering considerations of the accessibility stack.        
  General Comments: Levels MS06: Setting realistic Level A, AA, and AAA success criteria We think that many of the current A success criteria do not meet the test of a,b,c,d as defined in our original comment. For example:        

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) with an indicator that the alternative content is present (1.1.2) or a placeholder replacing the non-text content (1.1.3) . It's recommended that users can also choose at least one alternative, such as alt text, to be displayed by default (1.1.4). It's recommended that caption text or sign language alternative cannot obscure the video or the controls (1.1.5) and that 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) MS06: 1.1.2 what requirement of WCAG does this support? Also, this would be better handled by AT than by a browser. It supports UAAG 1.1.1, and provides notification to users who want alternative content but are not using assistive technology. E.g. for example a person who has difficulty processing abbreviations can see which acronyms have definitions.



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) MS06: 1.1.3 What requirement of WCAG does this support?
People who want low contrast that find high contrast painful. People with cognitive issues who want to suppress icons and see alt text.



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) MS06: 1.1.4, 1.1.5 are 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)
* Don't obscure controls: Displaying time-based media alternatives doesn't obscure recognized controls for the primary time-based media.
* Don't obscure primary media: The user can specify that displaying time-based media alternatives doesn't obscure the primary time-based media.
* Use configurable text: The user can configure recognized text within time-based media alternatives (e.g. captions) in conformance with 1.4.1.
MS06: 1.1.5 first two bullets seem like A to support WCAG 1.2. I believe the third bullet is required under CVAA but not WCAG, so can stay AA
UAWG agrees.
Accept



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)
* Resize: The user can resize alternative content for time-based media up to the size of the user agent's viewport.
* Reposition: The user can reposition alternative content for time-based media to two or more of the following: above, below, to the right, to the left, and overlapping the primary time-based media.
MS06: 1.1.6 is also required by CVAA, but can stay AAA
UAWG agrees.
Accept



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)
* The user agent doesn't attempt to repair the text alternatives by substituting text values that are also available to assistive technologies.
* The user agent makes available metadata related to the non-text content available programmatically, but not via fields reserved for text alternatives.





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)
* Labels
* Headers (e.g. heading markup, table headers)






Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links MS06: 1.3 should be refactored so that level A requires picking up OS settings for these things where they exist, and levels AA or AAA would require adding features beyond what is available on the OS settings, as described in current 1.3.1 and 1.3.2
UAWG agreed 5.1.3 covers the requirement to pick up OS settings. We agree to reword 5.1.3 to make it more clear. 1.3 was also rewritten for effective testing.





Summary: The user can visually distinguish between 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)
* Selection
* Active keyboard focus (indicated by focus cursors and/or text cursors)
* Recognized enabled input elements (distinguished from disabled elements)
* Recently visited links
* Found search results





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)
* Foreground colors
* Background colors
* Borders (color, style, and thickness)
* Size when the indicator is an image
* Blink rate (where implemented)






Guideline 1.4 - Provide text configuration MS06: 1.4 Should be refactored so that level A requires picking up OS settings for basic text settings where they exist, and levels AA or AAA would require adding features beyond what is available on the OS settings





Summary: The user can set text scale, color, style, line spacing, and font family globally (1.4.1, Level A). It is recommended that users set text size, color, line spacing, text style and font family for element types (1.4.2, Level AA); set character spacing, justification and margin sizes globally (1.4.3, Level AA); set capitalization, hyphenation, and borders globally (1.4.5, 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.5 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 Basic text formatting (Globally): The user can globally set all of the following characteristics of visually rendered text content: (Level A)
* Text scale with preserved size distinctions (e.g. keeping headings proportional to main font)
* Text color and background color, choosing from all platform color options
* Font family, choosing from all installed fonts
* Line spacing, choosing from a range with at least three values
MS03: Separation between browsers and OS We still believe that 1.4.1 should be separated into a level A criterion to pick up the OS settings where they exist, and level AA or level AAA criterion to go beyond the settings available on the platform.



AA 1.4.2 Basic text formatting (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings, input fields, and links: (Level AA)
* Text size or scale
* Text color and background color, choosing from all platform color options
* Font family, choosing from at least all platform fonts
* Line spacing, choosing from a range with at least three values
* Text style (underline, italic, bold)
MS06: 1.4.2 should be handled by AT




AA 1.4.3 Blocks of text (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AA)
* Character spacing, choosing from a range with at least 5 values
* Justification (left or right, including turning off full justification)
* Margins around blocks of text
MS06: 1.4.3 should be handled by AT





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 the rendered content, and the following are all true: (Level AA)
(a) any visual, non-time-based, rendered content can be printed
(b) the user can choose between available printing devices
(c) the user can have content printed as it is rendered on screen, reflecting any user scaling, highlighting, and other modifications
(d) the user can have printed content reflow as if the top-level viewport had been resized to match the horizontal dimension of the printing device's printable area





AAA 1.4.5 Advanced text formatting (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AAA)
* Capitalization (overriding upper case and small caps style)
* Word-breaking properties (e.g. auto-hyphenation)
* Borders
MS06: 1.4.5 why is a global setting lower priority than a per-object setting? It seems far easier to implement and more useful.





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 MS02: Separation of assistive technologies from user agents We accept the UAAG disposition. However, we think it would be useful to take some of the text from your response to our comment and add it as a note in the document.




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)
* Speech rate
* Speech volume (independently of other sources of audio)
* 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)
* Pitch (average frequency of the speaking voice)
* 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: If synthesized speech is produced, 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)
* User-defined extensions to the synthesized speech dictionary.
* "Spell-out": text is spelled one character at a time, or according to language-dependent pronunciation rules.
* 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).
* 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 MS06: 1.7 user style sheets should be AAA. They are not a feasible solution. They don't work with the modern web, where styles are used for UI configuration, and they are too technical for typical end users. Style sheet modification makes some sense as a programmatic interface available to AT developers, but not as an end-user feature.





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). MS08: Realistic expectation of the end users We still do not agree that user stylesheets are a reasonable end user feature. User Stylesheets are too technical to be an end user feature. They make sense only as a programmatic interface available to AT developers. We would be satisfied if the references to "users can" were changed to "AT can" or "developers can".



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)
* All pages on specified websites, or
* 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: Regarding SB01 (not sure if 1.7.4 Save Copies of Stylesheets is really needed), yes the new additional explanation is good, especially the point about making sure the stylesheet is pretty-printed (which is not usually possible if you simply inspect the page's source code and fetch the stylesheet URLs from it, which is what I'm in the habit of doing).

Highly complex stylesheets can still be difficult to make sense of though, even when pretty-printed. Some current browsers have "inspect this element" functionality which can help here - they tell you exactly which CSS rules were applied to the element you pointed at, and, as a bonus, include any overrides that were generated by a script rather than a CSS file.

One addition that might be useful is in the case when a page's styles come from not just one CSS file but quite a lot of them (I've seen sites with over 20 CSS files all loaded from the same page, and no they weren't alternates, they were ALL applied) - the user might choose whether to save them individually or to merge. But I wouldn't worry too much about a browser lacking that addition.

And one reason why it might be a good idea to have this function from inside the browser (rather than relying on command-line tools like "wget") is the page might be available only from behind a "login" page, and it's often quite a chore to set up wget with the correct authentication cookies just to get a copy of all the CSS files. (True, some servers will serve the CSS files even without correct authentication, but that's not always the case.)






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.7, Level AA), keeping the focus within the viewport (1.8.2 & 1.8.6, Level A), resizing the viewport (1.8.8, 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.9, Level AA). The user can specify that all viewports have the same user interface elements (1.8.12, Level AA), if and how new viewports open (1.8.10, Level AA), and whether the new viewport automatically gets focus (1.8.11, Level AA). The user can specifiy that multi-column text blocks be reflowed into a single column (1.8.14, Level AA), that the user can override absolute layout dimensions (1.8.15, Level AA), and linearize the content (1.8.16, Level AA). The user can mark items in a web page and use shortcuts to navigate back to marked items. (1.8.17, 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)
* Zoom in: to 500% or more of the default size
* 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)




AA 1.8.7 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.8 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.9 Provide Viewport History: For user agents 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: (Level AA)
(a) restored point of regard
(b) input focus
(c) selection, and
(d) user's form field entries
MS06: 1.8.9 seems difficult to implement and should be AAA




AA 1.8.10 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)




AA 1.8.11 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) SB03: Regarding SB03 (1.8.11 Allow Top-Level Viewport Open on Request), I believe the problem I mentioned is caused by scripts intercepting the "mousedown" or "mouseup" event (rather than the "click" event), and therefore intercepting middle-clicks and (unintentionally?) causing these to perform some action on the page instead of opening the link in a new window. One solution might be to allow the user to specify which mouse buttons are allowed to generate Javascript events. For example, if the user says "do not allow any mouse buttons to generate Javascript events" then no click or mousedown / mouseup events are generated and clicks always perform the default browser behaviour; if the user says "allow only the left mouse button to generate Javascript events" then the other buttons will not; if the user says "allow left and right but not middle" then pages can override context menus but cannot override whatever the middle button is bound to (e.g. "open in new tab"). I'm not sure how exactly these options should be described to the user, or where to put them (probably in an "advanced" section somewhere), but being able to tell the browser not to generate JS events when I middle-click would stop a lot of annoying sites from overriding this "open link in new tab" shortcut. (Yes, there will be times when the site is so script-driven that "open in new tab" can't work anyway, but in these cases the user would find out soon enough; I find in most cases "open in new tab" certainly CAN work - and DOES work when you bring up the context menu and select it from that - but the site simply prevents middle-click from doing that job.)




AA 1.8.12 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)




AA 1.8.13 Multi-Column Text Reflow: The user can specify that recognized multi-column text blocks each be reflowed into a single column. (Level AA)





Note: Some layouts may become unusable if author-specified layout is overridden. In this case, the user can turn linearization off and try another strategy. It is recommended that user agents provide a convenient way for the user to turn this behavior on and off.




AA 1.8.14 Ignore Absolute Layout Dimensions: The user can have the user agent override author-specified absolute layout dimensions. (Level AA) MS06: 1.8.14 will break a lot of content and is a bad idea. It is also too technical to be an end user feature, and should only (maybe) exist as a programmatic interface for AT developers. If it is determined that it can be implemented without breaking things, then AAA The rest of 1.8 levels look ok




AA 1.8.15 Linearize Content: The user can have recognized content rendered as a single column, overriding author-specified formatting of columns, tables, and positioning. (Level AA)





Note: Some layouts may become unusable if author-specified layout is overridden. In this case, the user can turn linearization off and try another strategy. It is recommended that user agents provide a convenient way for the user to turn this behavior on and off.




AAA 1.8.16 Provide Web Page Bookmarks: The user can mark items in a web page, 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 content. (1.9.1, Level AA).




AA 1.9.1 Outline View: Users can view a navigable outline of the rendered content that allows focus to be moved to the corresponding element in the main viewport. (Level AA)





Note: The elements reflected in the outline view depend on the web content technology, and 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 the information from explicitly-defined relationships in the content, including at least the following: (Level AA)
(a) label for a control or image (e.g. HTML label element, figcaption or aria-labelledby attributes)
(b) caption for a table
(c) row and column labels for a table cell
MS06: 1.10.1 should not be an end user feature, but a programmatic interface for AT developers. It is much too technical, especially since it is targeted at users who have trouble understanding the simpler user-facing renderings of those relationships. We could get behind level A for creating an API for AT to use, but it should either be AAA or gone as an end user feature.
UAWG has reworded 1.10.1 and are only asking that information that is being sent to API, so that that people who are not using AT can still understand context.



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: Modality Independence: 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, that works best for a given situation. If every potential user task is made accessible, so multiple modalities are supported, that a user can choose 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. Another example is a user on a mobile device that lacks keyboard who uses uses taps, wirelessly connected devices, and voice commands to simulate discrete or keyboard input. 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 the 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 rendered content of 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) MS06: 2.2.3 is a bad idea. Defaulting to source order is a bug, not something to be codified. You are preventing browsers from implementing navigation based on visual rendering, which many add-on AT products support, and which is often a better solution. If it must be kept, make it AAA The rest of 2.2 looks ok for level
UAWG has rewritten the SC and increased the level to AA



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 elements (2.3.1, Level AA) with the option to immediately activate operable elements (2.3.2, Level AA). Display commands with the elements to make it easier for users to discover the commands (2.3.3 & 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 Enabled Elements: The user can move keyboard focus directly to any enabled element in the rendered content. (Level AA) MS06: 2.3.1 is not always a good idea. Some content has too many enabled elements to provide keyboard shortcuts to them all. If it stays, it should be AAA, as it is not necessary for meeting WCAG. 2.3.2 see 2.3.1
UAWG has existing examples like Mouseless Browsing extension. Speech input users need it more when there are a lot of links on the page.
Not accepted


AA 2.3.2 Allow Direct Activation of Enabled Elements: The user can, in a single action, move keyboard focus directly to any enabled element in the rendered content and perform an activation action on that element. (Level AA) MS06: 2.3.1 is not always a good idea. Some content has too many enabled elements to provide keyboard shortcuts to them all. If it stays, it should be AAA, as it is not necessary for meeting WCAG. 2.3.2 see 2.3.1




AA 2.3.3 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)




AA 2.3.4 Present Direct Commands in User Interface: The user can have any direct commands in the UA 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 UA 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 in an accessible manner 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) MS06: 2.5.1 is vaporware, and should be AAA or removed. If we knew how to do this, we wouldn't need WCAG or SVG ARIA.
UAWG agrees and will remove it.
Accept


AA 2.5.2 Provide Structural Navigation by Heading and within Tables: The user agent provides at least the following types of structural navigation, where the structure types are recognized: (Level AA)
* By heading
* By content sections
* Within tables
MS06: 2.5.2 could be A. It is needed to meet WCAG 1.3
UAWG decided that it was still not such a simple thing to provide that it would be A. It does not mitigate a blocking user need.
Not Accept


AAA 2.5.3 Configure Structural Navigation and Views: The user can configure which elements are used for structural navigation and outline views. (Level AAA)





Guideline 2.6 - Provide access to event handlers MS06: 2.6 should be AAA or advisory. Its implementability is an area of open debate. It's less vaporware than 2.5.1, but still not a solved problem.





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)

SB04: Regarding SB04 (stop event handlers) - glad the example has been added to the Reference to 2.11.3. It comes up on quite a few sites. Only problem now is: OK, so you can stop the scripts so they can't cause the page to flicker, but then when you come to click on the control, what if that click is processed ONLY by a script? You are then in the position of having to (1) position the mouse, (2) start scripts again, and (3) click. (And hope that the "flickering" problem doesn't start up again between steps 2 and 3, which it almost certainly will.) So I think it would be very nice to have some functionality that says "stop the scripts until my next click - and when I click, start the scripts again just before processing the click".

(And yes I do know that I can give keyboard focus to the element, turn on scripts, and press an appropriate key, but that might not work if the page's author did not think to implement a keyboard alternative to clicking - a lot of Javascript-only controls out there recognise only mouse events, unfortunately. I hope there's a guideline somewhere else that says it should be possible to simulate mouse events by key presses. But that's a different issue - if you WANT to use the mouse to click on a control, and that control is handled only by Javascript, and there's no way you can approach the control with the mouse without stopping scripts first, then it would be nice if there were some way of saying "please turn Javascript back on just before processing this click".)

One other solution to this specific problem might be to have an option that simply disables events like "onMouseEnter" and "onMouseOut" - in other words, let me move my mouse around over the window without telling any of the scripts on the page where my mouse cursor is. (Of course, when I click, THEN it will have to fire the "onMouseEnter" event before the "click" event, otherwise a lot of scripts might break. But don't send the "onMouseEnter" event when the user is just moving the mouse without clicking.)

Or perhaps all we need is (maybe not at level A, but maybe at level AAA or something) - "automatically disable Javascript when not interacting with the page". I.e. when I click (or press any button on the keyboard), enable scripts to handle that event, and automatically disable them shortly after (how shortly? ideally "when the event handling is finished"). That way, we won't have scripts messing up the display based on a background timer or random mouse movements, but we can still use functions of a page that are implemented in Javascript.

Although I still think it would make more sense to disable specific Javascript events, rather than trying to turn on and off the whole interpreter at the correct times. "Disable Javascript timer events" and "disable Javascript mouse-motion events" are definitely options that I would switch on at nearly all times (except on sites where you really can't get to the content without letting onMouseOver happen).

Perhaps it should be worded as something like "prevent scripts from modifying the page in response to merely pointer motion", with a suggestion that this might be implemented by stopping the entire interpreter at appropriate times, or by suppressing certain Javascript events - we say what result we want and leave it to the browser implementors to decide how to do it. (Really clever implementors might want to let scripts run anyway but fail any attempts they make to change the DOM, or allow changes to proceed but don't actually display the result - but we needn't go into that. Stopping the interpreter or suppressing relevant events should be fine, just as long as it's possible to switch it all back on just before the crucial 'click' is processed.)






Guideline 2.7 - Configure and store preference settings MS06: 2.7 needs a level A about picking up OS settings. The rest look ok for level





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 settings 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)





Note: User agents may have a public access setting that turns this off.




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 UA 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)
* 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.
* 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).
* 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).
* Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls.
* 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: The UA user interface does not include time limits or at least one of the following is true: (Level A)
(a) Turn Off: Users are allowed to turn off the time limit before encountering it; or
(b) Adjust: Users are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
(c) Extend: Users are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. "press the space bar"), and users are allowed to extend the time limit at least ten times; or
(d) Real-time Exception: The time limit is a required part of a real-time event and no alternative to the time limit is possible; or
(e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
(f) 20 Hour Exception: The time limit is longer than 20 hours.






Guideline 2.10 - Help users avoid flashing that could cause seizures MS06: 2.10 can't be A. We are not at all sure this is implementable. The browser does not always know how something will flash. Flash rate is dependent on script, system state (is my swap file full? It will run slower) and hardware.





Summary: To help users avoid seizures, the default configuration prevents the browser user interface 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.11.7, Level AA). It is recommended that the user can adjust contrast and brightness of visual time-based media (2.11.8, Level AAA). Enable or disable tracks is included in 1.1.1 Render Alternative Content.




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)
* Playback Rate: The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time.
* Pitch: Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality.
* Synchronization: Audio and video tracks remain synchronized across this required range of playback rates.
* 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) MS06: 2.11.7 might make more sense as AT than mainstream UA requirement




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 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) MS06: 2.12.2 should be A. It is required for WCAG and is easy to implement




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) MS06: 2.12.3 should be at least AA, maybe A. It is required for WCAG, and is easy to implement on any platform with an accessibility API. Have you gotten feedback that it's hard?





PRINCIPLE 3: Ensure that the user interface is understandable





Guideline 3.1 - Help users avoid and correct mistakes





Summary: Users can undo text entry (3.1.1, Level A), avoid or undo settings changes (3.1.2, Level A), and receive indications of progress activity (3.1.3, Level A). It is recommended that users can have their text checked for spelling errors (3.1.4, Level AA), go back after navigating (3.1.5, Level AA), have form submissions require confirmation (3.1.6, Level AA), have auto-form fill of basic information (3.1.7, Level AA), and save form entry data with a local save (3.1.8, Level AA).




A 3.1.1 Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) CA01: We saw that 3.1.1 has been removed because it is untestable. What aspect was found untestable? Is it identifying what content is important or the task that the user is trying to perform? Could you provide more details?





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.1.2 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) MS06: 3.1.2 should be AA. It may be difficult to implement. I am not aware of any browser that currently support it. Requiring confirmation is easy, but greatly decreases usability.




A 3.1.3 Retrieval Progress: By default, the user agent shows the state of content retrieval activity. (Level A)




AA 3.1.4 Spell Check: The user can have spelling assistance for editable text in rendered content.. (Level AA) MS06: 3.1.4 should be A. All the browsers support it.




AA 3.1.5 Back Button: The user can reverse recognized navigation between web addresses (e.g. standard "back button" functionality). (Level AA)




AA 3.1.6 Form Submission Confirm: The user can specify whether or not recognized form submissions must be confirmed. (Level AA)




AA 3.1.7 Form Auto-Fill: The user can have the following information stored and used to auto-fill form fields by request: (Level AA)
(a) user's name
(b) user's email address
(c) user's phone number





AA 3.1.8 Save Form Entries: If the user agent provides a feature to save local versions of web content, then any form fields the user has filled retain any entries in the saved version. (Level AA)





Guideline 3.2 - Document the user agent user interface including accessibility features





Summary: User documentation is available in an accessible format (3.2.1, Level A), it includes accessibility features (3.2.2, Level A), it documents all the user features (3.2.3, Level AA), it delineates differences between versions (3.2.4, Level AA), and provides a centralized view of conformance UAAG2.0 (3.2.5, Level AAA).




A 3.2.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.2.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 UA 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.2.3 Document All Features: For each user agent feature, at least one of the following is true: (Level AA)
(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 UA 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.2.4 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.2.5 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.3 - Make the user agent behave in predictable ways





Summary: Users can prevent non-requested focus changes (3.3.1, Level A).




A 3.3.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 UA user interface, rendered content, and generated content, the user agent makes available the following via a platform accessibility service: (Level A)
* Name
* Role
* State
* Value
* Selection
* Focus





A 4.1.3 Provide Equivalent Accessible Alternatives: If a component of the UA 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) MS06: 4.1.4 DOM could be AA. Providing AT developers a way to go around accessibility APIs is not always a good thing, as it results in inconsistent user experiences based on the AT developers interpretation.




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 UA 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)
* Bounding dimensions and coordinates
* Font family of text
* Font size of text
* Foreground and background color for text
* Change state/value notifications
* Highlighting
* Keyboard commands






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), allows 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 UA 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) MS06: 5.1.1 and 5.1.2 there is no such thing as a web-based user agent. see other comment. If it's web-based, it's content, not a user agent.





Note: This success criterion does not apply to non-web-based UA user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is recommended that developers of non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) .




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
* Allow authors to satisfy a requirement of WCAG 2.0
MS06: 5.1.1 and 5.1.2 there is no such thing as a web-based user agent. see other comment. If it's web-based, it's content, not a user agent.





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)