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:
7 April, 2015
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 22 issues received from 5 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
Previous comments on Last Call Working Draft

Comments Received from:

Note: done means that UAWG has process and answered the comment. confirmed means that the group has heard back from the commenter that the comments were accepted or there was no confirmation.

Silas Brown (SB)- 3 issues [done] confirmed
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0013.html
Lisa Seeman (CA - Cognitive Accessibility Task Force) - 1 issue [done] confirmed
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0001.html
Cynthia Shelly (MS -Microsoft) - 6 issues [done] *needs confirmation"
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html
Joseph Scheuhammer (JS - PFWG) - 3 issues [done] confirmed - Note: one issue was continued
https://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0080.html
Shawn Henry (SH - EOWG) - 9 issues [done] confirmed - Note: some issues were continued
https://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0071.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.

[done] Instead of removing web-based browsers from the scope of UAAG we have:

  • labeled in UAAG Reference the SCs that typically are implemented at the web-based browser level
  • added a section explaining this to the UAAG Introduction and/or conformance section
  • changed the definition of user agent (#def-user-agent) in the glossary to give more specific guidance.
Not accepted 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. [done] UAWG added this information to the Reference document in a new section for each SC: "Typically implemented by" Accepted substantive  
  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: [done]. see individual success criteria Partial accept substantive  

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. [done] 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.
Answered
Question

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?
[done] People who want low contrast that find high contrast painful. People with cognitive issues who want to suppress icons and see alt text.
Answered
Question

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
[done]
Accept
substantive

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
[done] UAWG agrees. UAWG split 1.1.5 into two different SC with different levels.
Accept
substantive


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
[done] UAWG agrees.
Accept
substantive


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
[done] 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.

Accept
substantive

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
[done] UAWG agreed and added a new success criteria 1.4.5. UAWG did not make changes to the levels.
Partial agree
substantial

  Guideline 1.4 SH04: *Inconsistencies*
I'm not sure if the inconsistencies below are on purpose or in error? :-)

* 1.4.1 Basic text formatting (Globally):… Text scale with…
1.4.2 Basic text formatting (by Element): … Text size or scale

* 1.4.1 Basic text formatting (Globally):…
Text color and background color, choosing from all platform color options
Font family, choosing from all installed fonts [this says "installed" &
others say "platform"]
1.4.2 Basic text formatting (by Element):
Text color and background color, choosing from all platform color options
Font family, choosing from at least all platform fonts

[done] UAWG choose the wording with care. Globally, text is scaled, but by element it can be sized or scaled. Fonts are installed, but colors are chosen from the platform. We reviewed the other success criteria to make sure the wording was consistent. Not accepted editorial No specific response. Her email ends with "I am fine with all the other changes noted above."

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. [done] UAWG added a new success criteria, 1.4.5, to pick up the OS settings. The new SC is Level AA. UAWG did not change the other SC levels. UAWG made additional changes to support this, which are itemized under SH08
Partial accept
substantive

  1.4.1 Basic text formatting (Globally): SH01: I'm afraid that below isn't specific enough and you need to say
something about specific values &/or increments.

1) * Current text: "Line spacing, choosing from a range with at least three values"
As it is written, a user agent that provided 1.0, 1.1, 1.2 would meet
this criteria; however, that doesn't meet the needs of most users who
need increased line spacing, as most need between 1.25 and 2.0.

[done] UAWG changed 1.4.1 to
* Line spacing, choosing from a range with at least three values up to at least 2 times the default. UAWG added Note 4 to the introduction of 1.4:
Note 4: When it comes to magnification, size, or spacing, the optimum value for a given user would vary based on their visual impairment and the size of the content they’re reading. Therefore it’s recommended that user agents provide a wider range of values, and a greater number of increments, to allow the user to adjust the view for their current task.
UAWG added a sentence to the Intent of 1.4.1:
At a minimum, it is recommended to offer line spacing options of 1, 1.25, 1.5 and 2.0.
Accept substantive

SLH: Interesting way to cover it. Seems like it will work well along with the specific suggestions in the Reference. SLH: I note 1.4.1 says: * Line spacing, choosing from a range with at least three values up to at least 2 times the default * Text style, choosing to turn on/off underline, italic, bold and 1.4.2 says: * Line spacing, choosing from a range with at least three values * Text style (underline, italic, bold) Should these be the same or is there a reason that they are different?

SLH: [minor] "When it comes to magnification, size, or spacing, the optimum value for a given user would vary based on their visual impairment..." limits users who need this to people with visual impairment; however, many people with cognitive impairments also need uncommon text size and spacing especially. An idea to make it more broadly encompassing and simple is to replace the first sentence with: "Users have varying needs for text size and spacing."

> UAWG added a sentence to the Intent of 1.4.1:
>http://w3c.github.io/UAAG/UAAG20-Reference/#sc_141-i
> At a minimum, it is recommended to offer line spacing options of 1, 1.25, 1.5 and 2.0.

SLH: I agree that it's good to leave some flexibility in the normative standard and then provide specific suggestions in the informative Reference. Good work!

  1.4.1 Basic text formatting (Globally): SH05: *missing* "Text style (underline, italic, bold)"
Current text has it only provided by Element; it is missing from Globally.
[done] UAWG added a bullet to 1.4.1: Text style, choosing to turn on/off underline, italic, bold Accept substantive

No specific response. Her email ends with "I am fine with all the other changes noted above."

  1.4.1 Basic text formatting (Globally): SH08: "Note: Any user settings from the platform for these characteristics
are implemented."
I cannot figure out what this means.
[done] This note was added in response to comments from Microsoft in MS03. UAWG removed the note and took the following actions: a) removed the note from 1.4.1 and 1.3.1 because the notes are too broad b) added a new success criterion "1.4.5: Default to platform text settings: The user can specify that platform text settings be used as the default values for text configuration. (Level AA)" c) clarified 5.1.3 so that it only applies to implementing the accessibility guidelines of the platform and not to user settings d) removed 1.4 note #1 because it was incorporated into the success criteria handles e) moved 1.4 note to Conformance Applicability Notes     No specific response. Her email ends with "I am fine with all the other changes noted above."
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

[done] UAWG decided that 1.4.2 was important for people who do not necessarily use AT, and there are implementations using user stylesheets or in Extensions. UAWG added a section in Reference "Applies To" for each success criteria.

Not accepted
substantive

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
[done] See 1.4.2 In addition, UAWG removed the note (which no longer applied). UAWG added a section to each success criteria in Reference, "Applies To".
Partial accept
substantive


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




  1.4.3 Blocks of text (Globally) SH03: * Current text: "Character spacing, choosing from a range with at least 5 values"
This may have the same issue as above, although maybe not because the
range of character spacing needed is far less, afaik.
[done] UAWG added a sentence to UAAG Reference: "It is recommended to provide a range of character spacing of at least 0.01, 0.03, 0.06, 0.09 times the base character width. " Accept substantive No specific response. Her email ends with "I am fine with all the other changes noted above."
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.
[done] UAWG decided to remove the word "global".
Accept
Substantive

  1.4.5 Advanced text formatting (Globally) SH06: * I had suggested more element-level customization at Level AAA that is missing from the current text. Given that it at Level AAA, does it make sense to leave it in there? [done] UAWG moved around the levels of element-level customization and we believe that all of the items are included with the exception of Word spacing, which we had deliberately removed.
Partial accept substantive

SLH: In the latest Editor's draft, I am still not able to find the following for element-level: * Margins * Borders (fyi, These seem to be commonly-used ways to help indicate different heading levels by advanced user stylesheet users, e.g., see <http://www.tader.info/ex-displays.html>)

  1.4.5 Advanced text formatting (Globally) SH07: Word spacing seems to be missing all together. Is that an error or
conscious decision?
[done] UAWG put word spacing back as a new bullet in 1.4.5 Word spacing, choosing from a range with at least 5 values Accepted substantive No specific response. Her email ends with "I am fine with all the other changes noted above."

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. [done] UAWG added a note to 1.6: "If browsers provide speech output for mainstream users, they should make the speech configurable enough to be usable by a wide range of individuals. When an extension adds speech output to the user agent, it becomes part of the user agent, and therefore should meet the requirements of 1.6."
Accept
substantive

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.
[done] see success criteria below for individual changes




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". [done] UAWG has found implementations of user stylesheets and have received positive comment from other major browser to keep user stylesheets.
Not accepted
substantive

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) MS06, MS08
[done] UAWG agreed to change the level to AA. Examples do exist, so we did not want to change it to AAA. There are extensions and browsers that provide a non-expert user interface, so it can be done.
Partial accept
substantive

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
MS06, MS08
[done] UAWG agreed to change the level to AA. Examples do exist, so we did not want to change it to AAA. There are extensions and browsers that provide a non-expert user interface, so it can be done.
Accept
substantive
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.)

[done] UAWG added a new paragraph to the Intent of 1.7.4.
Accept
substantive
Accepted

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
SH02: * Current text: "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..."
As it is written, a user agent that provided just two options for zoom:
100% and 500%, would meet this criteria; however, that's not
sufficiently accessible because the vast majority of users who need zoom
will need it at a percent in between 100 & 500%.
[done] UAWG does not accept the comment because this is already well implemented, the UA already have nearly infinite zoom up to 500%. UAAG wording is agnostic and allows UAs to use what ever method to provide the scaling to 500%
Not accepted
substantive

SLH: I agree that most UAs today provide zoom at any increment - yeah! I do still think it is *very important that the standard include what users need*, even if it is already implemented in today's UAs -- to ensure that it is included in future UAs. (fyi, A common UA today provides the following zoom options in its interface: 10, 25, 50, 75, 100, 125, 150, 200, 400, 800, 1600, 2400, 3200, 6400. So between 150% and 400% --probably the most commonly-needed range-- there is only one option: 200%, which leaves out a lot of users' needs.)

 

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
[done] UAWG decided to remove selection because it was difficult, and we added an (informative) note that that recommended that selection also be restored. We found implementations of (a), (b) and (d) and did not change the level.
Partial accept
substantive

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.)
[done] UAWG did not accept this comment because 1.8.11 is only concerned about IF the new window captures focus. The middle-button-click is too technology specific to belong in the success-criteria.
Not accepted
substantive
Accepted
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) SH09: And some typos-type stuff I noticed:
* "The user can specifiy that multi-column text blocks be reflowed into
a single column (1.8.14, Level AA)"
specifiy -> specify
* "Summary: ... The user can specifiy that multi-column text blocks be
reflowed into a single column (1.8.14, Level AA)"
doesn't match below: "1.8.13 Multi-Column Text Reflow:" ... "1.8.14
Ignore Fixed Unit Dimensions:"
[done]
Accept
editorial No specific response. Her email ends with "I am fine with all the other changes noted above."

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
[done] UAWG changed the wording to remove "absolute layout" and added an example in the Reference.
Partial accept
substantive

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.
[done] 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.
Partial accept
substantive
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
[done] UAWG has rewritten the SC and increased the level to AA
Partial accept substantive

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
[done] 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
substantive

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
[done] 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.
[done] UAWG agrees and will remove it.
Accept
substantive

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
[done] 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
substantive

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.
[done] UAWG also agreed that it was not testable and had no implementations. It was decided to remove it.
Accept
substantive


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

[done] UAWG reluctantly realized that the success criteria was not testable and had no implementations and removed it.
Not accepted
substantive
Accepted

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
[done] UAWG agreed that 5.1.3 covers picking up OS settings. A reference to 5.1.3 was added to the Reference doc.
Partial accept
substantive

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.
[done] UAWG clarified the success criteria so it only applies to flashing in the chrome (aka user agent user interface). Browser developers should be able to control the amount of flashing their own user interface does.
Partial accept
substantive


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
[done] UAWG has identified implementations outside AT. Mainstream uses are also increasing and include journalists and archivists. It is possible to jump between chapters in mainstream media player including Quicktime and RealMedia.
Not accepted
substantive

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
[done] UAWG removed 2.12.1 and 2.12.3 because they were merged into 2.12.3 and 2.1.1. It was difficult to tell the difference between the versions of 2.12.1-3. 2.12.3 was changed to AA. We cross referenced 2.1.1 and 2.12
Partial accept
substantive
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?
[done] UAWG merged 2.12.1 and 2.12.3 with a level of AA.
Accept
substantive


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?
[done] presentation and email to CATF. CATF accepted the comments.
Answered at the CATF meeting CATF minutes
Question
Accepted at CATF meeting of 2014 July 21.

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.
[done] UAWG believes this is widely implemented where the setting change is reversed. We fixed a missing word that made it appear that the user was requesting confirmation.
Not accepted
substantive
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.
[done] UAWG decided that browsers on non-desktop do not all support it and it is not a blocking feature for accessibility, and decided to keep it at level AA.
Not accepted
substantive

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
JS01: First, not all content requires a name. For example, generally the content of an html

element, e.g.,

Hello world.

, doesn't need a Name. In fact, it's incorrect to take the content of the

element and make that its name, since its redundant. In this example, the name of the paragraph would be "Hello world", and the content would also be "Hello world". However, if the author wanted to call out that a particular paragraph is the summary of the current section, they could to the following:

Lorem ipsum dolor sit amet, consectetur ...

. So, if the role requires a name, and/or the author has provided it, then the UA must make it available. Secondly, and by implication, *if* the author has provided a description as well as a name, then the description should be made available as well. I'm leaning toward a UA making available any description Level A as well.
[done] UAWG agrees and changed the SC to include "if present"
Accepted
substantive
"Re: JS01 " 4.1.2 Expose Basic Properties", adding the phrase, "if present" is fine. "
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) JS02: I don't understand this one. It reads to me like, "If something can't be exposed through a11y services, then UAs must find an equivalent alternative and expose it". Is this a better way to put it: "If something can't be exposed through a11y services, then UAs must expose the equivalent alternative provided by the author"? The problem with the first reading is it requires UAs to be intelligent.
[done] UAWG clarified the success criterion so that it was more clear that it only applied to UA user interface components, not content widgets.
Accept
substantive Re:  JS02, " 4.1.3 Provide Equivalent Accessible Alternatives", the new wording is clear.  The new wording is much better.
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.

[done] UAWG does not feel that it is a bad thing for different AT to provide different user experiences. Such differences can be influenced by many factors, only one of which is their choice of gathering information via the DOM, platform API, and/or UA-specific means. We believe, that the field generally agrees, that diverse user experiences, and allowing the user to choose the tool that best supports their needs, is not only good but important. Typically, tools relying on platform API alone are able to provide a baseline-level of functionality across many applications, but other tools are able to provide a richer experience for specific applications by using a richer API. Users may choose one or the other based on their situation and needs. We believe that UA should support both approaches, and other reviewers have concurred, so DOM access is retained at Level A.

Not accepted
substantive

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) JS03: This one is tricky since it's a good principle. Unfortunately, for ARIA 1.0, this isn't allowed with respect to the values of aria-* attributes. The reason is that author scripts sometime rely on the value of aria-* attributes, and cannot know if something outside of the script, such as an AT, changes its. For that reason, the UAIG states that the flow of control is one-way only: http://www.w3.org/TR/wai-aria-implementation/#mapping_general (the second paragraph).
[done] UAWG agreed and re-phrased the SC so it is more narrow.
Accepted
substantive
Re: JS03, " 4.1.5 Write Access to the DOM", the new wording is better. [He then comments on discussion from the minutes of the meeting.] 
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.
[done] see MS01Instead of removing web-based browsers from the scope of UAAG we have labeled (in the reference document) the SCs that typically are implemented at the web-based browser level and we will be adding a section explaining this to the UAAG Introduction and/or conformance
Not accepted
substantive


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.
[done] see MS01
Not accepted
substantive


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)