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 Implementing UAAG 2.0
Working Drafts of 23 May 2013

Updated on:
24 September, 2013
This Version
Latest Version
Previous Version:

This is a working document from the User Agent Accessibility Guidelines Working Group (UAWG) that details action taken on the 125 issues received from 5 commenters on the working drafts of 23 May 2013 of UAAG 2.0 and Implementing UAAG 2.0. The table includes relevent text from UAAG 2.0 and Implementing UAAG 2.0; the classification of the comment, the UAWG response, and whether the commenter agreed with the change. There may also be highlighted text in the Response column whether or not the change has been accepted into the latest Editors' Draft.

See also:
UAAG 2.0 Working Draft of 23 May 2013
Implementing UAAG 2.0 Working Draft of 23 May 2013
List of Substantive Changes to UAAG 2.0 Last Call Working Draft

Comments Received from:

Education & Outreach Working Group (EO)
Anastasia Chetham & Jan Richards, OCAD University (OCAD)
Andrew Robertson (AR)
Alan Smith (AS)
John Foliot (JF)


Disposition of Comments

Priority Guidelines and Success Criteria Comments Type Response Disposition Acknowledgement

JF1: I believe that UAAG would have more impact if it employed RFC 2119 language, over vaguer instructions such as “can” and “it is recommended”.


JF1 [@@done] - Action-861

Added a note to clarify that guidelines do not use RFC language.

Alternative Action Taken

  Definition of Compliance Level

AR1: It isn't fair or indicative if a user agent is genuinely compliant in all AA or AAA criteria yet has to be regarded as non-compliant overall if only one level A criteria is non-compliant. This is another reason why exemptions for platform limitation changes should not just include hardware and OS, but the development platform where the author is not the user agent's vendor.


AR1 [@@done]Action-846 UAWG accepts that the wording for platform limitations was too narrow. Instead we will link to the definition of "platform" which includes host user agents, cross-OS environments (e.g. Java). However, the group also feels that the platform limitation should not extend to poor choices of UI component toolkits so this has been clarified in the definition of platform.


Partial Accept

  Overall Implementing Document

EO1: Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing.

EO2: Would the sections on Relationships to ATAG and WCAG be better in the Implementing document?



EO1 & EO2: [@@done]


accepted proposal  
  Overall (both)

EO3: Also, is there a reason why the "Guidelines" heading and each of the "Principles" headings are all at heading level H2?



EO3: [@@done]
We didn't want to lose a level of heading for 1 introductory item.


proposal not accepted

  Overall (Implementing)

EO23: (Implementing) Would it be possible to use structuring elements such as H5s to indicate sections like Intent of SC, Examples and resources? While comparing to the structure of Understanding WCAG 2.0, is there a W3C graphical design that could make each guideline document look similar?




WCAG differs from W3C stylesheet, UAWG is closer.

accepted proposal

not accepted

  Overall (Implementing)

EO24: (Implementing) Examples: change some of the names to be more diverse



EO24: [not done] Kim will generate new names for Implementing UAAG 2.0 document as we continue work on Implementing.


accepted proposal

  Overall (Implementing)

EO25: (Implementing) CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout.





accepted proposal

  Overall (Implementing)

EO26: (Implementing) change "Return to Guideline" to @@



EO26:[@@done]discussed with Shawn for exact proposal


accepted proposal

Accepted 20130916

EO4: Second sentence in abstract:
"User agents include browsers and other types of software that retrieve and render Web content."
It may be useful to indicate what "other types of software" is meant in addition to browsers.



EO4: [@@ done] browsers, media players and applications


accepted proposal


EO5: Second paragraph, second sentence: "technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities."
Perhaps it should be made clearer that the responsibility for Braille rendering will need to remain a function of the assistive technologies.



EO5: [@@ done](e.g. assistive technologies for braille rendering)


accepted proposal


EO6: Third paragraph, has a couple of errors in the acronyms: "the W3C" has "W3C" expanded to "the World Wide Web Consortium", so the word "the" is in both plain and title text (this happens elsewhere on the page too); "Web Accessibility Initiative" is written in full but its acronym is also expanded (incorrectly), so the output is "Web Accessibility Initiative the Web Access Initiative".


EO6 [done]

accepted proposal


EO7: First paragraph: it's not clear to me what "...and through other internal facilities..." means


EO7 [@@ done]removed phrase


accepted proposal


EO8: "This section is informative." Should change this to a header: "Informative Section". Other alternatives: reword it to "The section that follows is informative or add a colon so that readers know what follows is information. Otherwise, it's not clear cwhat "this" means - does it refer to the section that follows or the section that the hyperlink points to?


EO8 [@@ done]reworded

accepted proposal


EO9: Suggest changing: "Accessibility involves a wide range of disabilities." to "Accessibility involves consideration of a wide range of disabilities."


EO9 [@@ done]
changed as suggested

accepted proposal


EO10: May be the Working Group can bring more clarifications on the second sentence of follwoing paragraph, give an example of features concerned:
"Some UAAG 2.0 requirements may have security implications, such as communicating through Application Program Interfaces (API), or allowing programmatic read and write access to content and user interface control. UAAG 2.0 assumes that features required by UAAG 2.0 will be built on top of an underlying security architecture. "


EO10 & EO11: [@@ done] added note in 4.1


partial accepted


EO11: The fourth paragraph seems like it could be a set of bullet points:

"Some UAAG 2.0 requirements may have security implications, such as:

  • Communicating through Application Program Interfaces (API)
  • Allowing programmatic read and write access to content and user interface control.

In such cases, UAAG 2.0 assumes that features required by UAAG 2.0 will be built on top of an underlying security architecture. "

editorial EO11: [@@ done] see EO10. The paragraph was changed to a one sentence Note in Guideline 4.1 Not Accepted  
  Layers of Guidance

EO12: I would link from the 3 bullet items - Principles, Guidelines, Success Criteria - to where readers can read the specifics of each of these items - i.e. where they can read the 5 "principles"


EO12: [@@ done] There was no section with generic explanations to link to. We added more explanation and listed the 5 Principles.

alternative action taken

  Layers of Guidance

EO: 13: The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading Principles 4 and 5 are new and need more than just naming. The meaning of facilitate programmatic access and comply with specifications and conventions is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear.




EO13 [@@ done]
Action- 856

More explanation was added for all Principles


alternative action taken


  Layers of Guidance

EO14: Perhaps a nested list would help too because separation (and therefore an understanding) of principles 4 and 5 is complicated by the need to use the word "and" twice so closely together. On first reading this sounded like one principle to me.


EO14 [@@ done] [ proposal] Action- 856 A nested list was added.

Proposal Accepted

  Layers of Guidance

EO15: The three different levels of conformance are not obvious to read, in particular level A. The way it is written, it makes believe that there is a highest level whereas the highest level is called A. therefore, it may be helpful to write that the lowest level is called A and the highest is called AAA.
Text concerned: "Three levels of conformance meet the needs of different groups and different situations: A (lowest), AA, and AAA (highest). {Sylvie June 13}


EO15 [@@ done] [proposal] Action- 849

UAWG did not change "lowest/highest" to stay consistent with WCAG, but we added "basic"to A and "recommended" to AA.




Partial Accept  
  Layers of Guidance EO16: First paragraph includes the following items "...explanatory intent, examples and resource links." The way this section is written, I expected these items to have their own bullet points. If these items don't get their own bullets (or possibly are meant to be included under the bullet "success criteria"), then the first paragraph needs to be rewritten to reflect this meaning.

For example, this paragraph might read:

In order to meet the needs of different audiences using UAAG, several layers of guidance are provided, including overall principles, general guidelines and testable success criteria. Each layer may include explanatory intent, examples and resource links.
substantive EO16 [@@ done] [proposal] Action- 849 UAWG accepted with additional clarification that they are in a separate document. Accepted Proposal  
  UAAG 2.0 Supporting Documents EO17: (referred to as the "Implementing document" from here on) should probably read as (hereafter referred to as the "Implementing document") editorial EO17 [@@ done] Accepted Proposal  
  Components of Web Accessibility EO18: As this section directly references ATAG and WCAG, perhaps it should be followed by the sections that explain the relationship between UAAG and the other two sets of guidelines. Perhaps even move the "Relationship" sections into the Implementing document and link to them? editorial EO18 [@@ done] Accepted Proposal  
  Levels of Conformance EO19: I don't understand one of the "Factors that were considered in the process of determining the level to a success criterion", fourth bullet:
"implementation difficulty – ranging from deterministic to inferential"
editorial EO19 [@@ done] Accepted Proposal  
  Levels of Conformance EO20: plainer terms would make the meaning clearer and easier to translate. editorial EO20 [@@ done] Accepted Proposal  
  Definition of User Agent (Implementing)

AR2: There should also be a distinction between s/w developed by a vendor vs s/w developed in-house using a platform purchased from a vendor.

substantive AR2: [@@done]UAAG20 can certainly be applied to software developed in-house, and the working group recommends that companies adopt UAAAG20 as an internal policy. However, UAAG20 is a set of guidelines rather than a regulatory document, and whether a company is obligated to follow them will depend upon their regulatory environment, internal purchasing policies, etc. Proposal not accepted  
  Definition of a User Agent EO21:This appears to be identical to the "Definition of a User Agent" in the Implementing document. Could it be tersified in one or the other? editorial EO21: [@@ done] - coding error - only in one document Accepted Proposal  
  What Qualifies

EO22: I had trouble with the What Qualifies section. The word order tends to make it more confusing than it needs to be. I understand that we need to include procedural as well as declarative languages, but is there any other kind of programming language. Are you making your point? Are you trying to say no programming language is excluded as a basis for generating user interface?

My revision:

What qualifies as a User Agent?

These guidelines employ the following tests to determine if software qualifies as a user agent. UAAG 2.0 divides potential user agents into

  • platform-based application
  • extension or plug-in
  • web-based application

If the following three conditions are met, then a platform-based application is a user agent:

  1. It is a standalone application, and
  2. It interprets any W3C-specified language, and
  3. It provides a user interface or interprets a procedural or declarative language that may be used to provide a user interface

Example Qual-1: A standard browser.

If the following two conditions are met then an extension or plug-in is a user agent:

  1. It is launched by, or extends the functionality of a platform-based application, and
  2. Post-launch user interaction is included in, or is within the bounds (run time scope) of the platform-based application

Example Qual-2: Any media player or browser enhancing extension.

If the following three conditions are met then web-based application is a user agent:

  1. The user interface is embedded in an application that renders web content, and
  2. The user interface is generated by a procedural or declarative language; and
  3. Either user interaction does not modify the Document Object Model of its containing document or it is controlled by a procedural or declarative language.

Example Qual-3: Don't have one.

I think the confusion in this section springs from lack of examples, and this also springs from the lack of example of a web-app UA in implementing. The distinction between a general web app and a web app UA is not defined clearly, and maybe the concept is not well defined. That is, perhaps a web-app behaves like a UA sometimes and not at others

editorial EO22: [@@ done] We deleted the section because it was not consistent with the normative definition, and reworked the definition to incorporate parts of the What Qualifies section. Alternate Action  
  What Qualifies EO26: (Implementing) Third paragraph: the link to "What Qualifies as a User Agent" is followed by the name of the current document in brackets, isn't this redundant? editorial [@@ done] See EO22 Alternative Action  
  What Qualifies EO27: I think comment from "Modality Independence Principle" is appropriate here. I like that they use easy-to-follow if-then conditions, but examples are needed for clarity. editorial [@@ done] See EO22 Alternative Action  
  Modality Independence

EO22.1: I thought I was going crazy until I noticed that the anchor in the TOC reads "Modality Independence Principle," while the section it links to is titled "Modality Independent Controls" These are very different things. I personally think this section is ok, just need to change the anchor link to "Modality Independent Controls."

editorial EO22.1: [@@ done] Action-860 Proposal Accepted  
  Relationship with WCAG 2.0

EO23.1: The relationship between UAAG and WCAG is not very clear: when the application is considered to be a user agent and when not. As WCAG applies in both cases, why is it mentionned here?

question EO23.1: [@@ done] Added reference to normative defintion of user agent. Proposal Accepted  
PRINCIPLE 1 - Ensure that the user interface and rendered content are perceivable          
Guideline 1.1 - Provide access to alternative content.          
Summary: The user can choose to render any type of alternative content available. (1.1.1). The user can also choose at least one alternative such as alt text to be always displayed (1.1.3), but it's recommended that users also be able to specify a cascade (1.1.5), such as alt text if it's there, otherwise longdesc, otherwise filename, etc. It's recommended that the user can configure the caption text and that text or sign language alternative cannot obscure the video or the controls (1.1.4). The user can configure the size and position of media alternatives (1.1.6).



A 1.1.1 Render Alternative Content: For any content element, the user can choose to render any types of recognized alternative content that are present. (Level A)

OCAD1: Is the phrase "For any content element " necessary? ...BTW: did the group ever look at this proposal (of mine)?: http://lists.w3.org/Archives/Public/w3c-wai-ua/2011AprJun/0086.html



OCAD1 - [@@ done] reworded "The user can choose to render any type of recognized alternative content that are present for a content element."

Added new SC 1.1.x

Accept Proposal  
A 1.1.1 Render Alternative Content JF2: is there something that speaks to this use-case: <abbr title=”World Wide Consortium”>W3C</abbr>?) substantive JF2 - [done] we added an example in the Implementation guide for <abbr> Accept Proposal  
  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 Replace Non-Text Content: The user can have all recognized non-text content replaced by alternative content, placeholders, or both. (Level A)

EO29: (Implementing) Several occurences in this guideline and may be elsewhere through the doc: in Intent of success criterion X, the document says that non text content is unusable, or "painful". I have never seen this term elsewhere in W3C docs and wonder if it is appropriate.



EO29: [@@ done]



Accept Proposal




A 1.1.2 Replace Non-Text Content OCAD2 Seems kind of extreme at Level A that the user should have the option to view captions with the video not displayed at all. substantive OCAD2: [@@ done] reworded The note addresses that they can supplement. That covers captions. Accept Proposal  
Note: At level A, the user agent can specify that an alternative content or placeholder replace the non-text content. At level AA success criterion 1.1.3 requires that the user can specify one format or placeholder to be used. At level AAA success criterion 1.1.5 requires that the user can specify a cascade order of types of alternative content to be used.          
AA 1.1.3 Configurable Alternative Content Defaults: For each type of non-text content, the user can specify a type of alternative content that, if present, will be rendered by default. (Level AA)

EO13: (implementing)

"Sally is blind. In the browser's preferences dialog box, Sally specifies that she wants alt text displayed in place of images, and that the document should reflow to allow the entire alt text to be displayed rather than truncated."

As screen readers retrieve the alt text content is it necessary for a blind user to request that the browser displays alt text rather than images? May be the example should be rewritten to reflect real use of alt text by blind users?



EO13: [@@ done][UAWG decided to change to low vision

Accept Proposal  
AA 1.1.4 Display of Alternative Content for Time-Based Media: For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the following are all true: (Level AA) (a) Don't obscure primary media: The user can specify that displaying time-based media alternatives doesn't obscure the primary time-based media; and (b) Don't obscure controls: The user can specify that the displaying time-based media alternatives doesn't obscure recognized controls for the primary time-based media; and (c) Use configurable text: The user can configure recognized text within time-based media alternatives (e.g. captions) in conformance with 1.4.1. OCAD3 (a) seems like a lot at AA, especially since captions typically overlay the lower portion of the video. Others make sense. substantive

OCAD3: [@@ done] reword

definition of Obscure Action-858

Accept Proposal  
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.5 Default Rendering of Alternative Content (Enhanced): For each type of non-text content, the user can specify the cascade order in which to render different types of alternative content when preferred types are not present. (Level AAA) OCAD4 Specifying the cascade would seem to lead to a confusing UI. Better to have a quick way to view all the options if the preferred one isn't available. substantive OCAD4: [@@ done] deleted Alternative Action  
AAA 1.1.6 Size and Position of Time-Based Media Alternatives: The user can configure recognized alternative content for time-based media (e.g. captions, sign language video) as follows: (Level AAA) (a) The user can resize alternative content for time-based media up to the size of the user agent's viewport. (b) The user can reposition alternative content for time-based media to at least above, below, to the right, to the left, and overlapping the primary time-based media.

EO29.1: (Implementing) In Examples of Success Criterion 1.1.6, the disability of the users is not always specified, (e.g. Maximilian or Tom




EO29.1[@@ done]

Accepted proposal  
AAA 1.1.6 Size and Position of Time-Based Media Alternatives OCAD5 This is a lot of configurability.  

OCAD5: [@@ done] reworded


Alternative Action  
AAA 1.1.6 Size and Position of Time-Based Media Alternatives OCAD6: Right-and-left is a challenge with horizontally flowing languages like English.   OCAD6: [@@ done] reworded Alternative Action  
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).

EO28: (implementing) Link to definition of metadata would be helpful


EO28: [@@ done] UAWG think it is a common term that has no special UAAG meaning

Proposal not accepted  
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) (a) the user agent does not attempt to repair the text alternatives with text values that are also available to assistive technologies. (b) the user agent makes metadata related to the non-text content available programmatically (and not via fields reserved for text alternatives).

OCAD7: ATAG SC on which this was once based is now more clear (B.2.3.2)...rules out "No Generic or Irrelevant Strings: Generic strings (e.g. "image") and irrelevant strings (e.g., the file name, file format) are not used as text alternatives"




OCAD7 [@@ donel] Action-875 on Jan and Greg






AA 1.2.1 Support Repair by Assistive Technologies: EO30: Implementing) Why is a link to "Website Accessibility Conformance Evaluation Methodology" a resource for this particular guideline. I followed the link which brought me to the very top of the Evaluation Methodology Document but I had no idea what I should be looking for or which section to look at. (WCAG-EM) 1.0 editorial EO30 [@@ done] Accept Proposal  
AA 1.2.1 Support Repair by Assistive Technologies: EO31: (Implementing) I think an example of what's stated not to do in a & b would be helpful. Otherwise, I'm not exactly sure what those instructions are warning against. substantive EO31 [done] UAWG decided to reword the examples Accept Proposal  
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) (a) Labels (b) Headers (e.g. heading markup, table headers) EO32: (Implementing) Examples of Success Criterion 1.2.2, first example:
The example talks about Franck who is called George in the next sentence. ^Try to check that the names remain the same in each example, in order to avoid confusing the reader.
editorial EO32 [@@ done] Accept Proposal  
Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.          
Summary: The user can visually distinguish selected, focused, and enabled items, and recently visited links (1.3.1), with a choice of highlighting options that at least include foreground and background colors, and border color and thickness (1.3.2).          
A 1.3.1 Highlighted Items: The user can specify that the following classes be highlighted so that each is uniquely distinguished: (Level A) (a) selection (b) active keyboard focus (indicated by focus cursors and/or text cursors) (c) recognized enabled input elements (distinguished from disabled elements) (d) elements with alternative content (e) recently visited links

EO34: (Implementing) It would be nice to know that more info is available in "Examples of Success Criterion 1.3.1:" for note items 1 & 2. I don't know if there's a way to indicate this without cluttering up the screen.






EO34 [@@done] UAWG decided that there is not a need to do this. The notes and examples are co-located. The visual clutter would reduce accessibility of the doc.







Proposal not accepted



A 1.3.1 Highlighted Items EO 35: (Implementing) missing word: In second bullet item under "Examples of Success Criterion 1.3.1": "so he tell where" should be "so he can tell where" editorial EO35 [@@ done] Accept proposal  
A 1.3.1 Highlighted Items EO36: (Implementing) 1st example under "Examples of Success Criterion 1.3.1:". When you refer to "website that uses styles to override visited link color", do you mean font style - such as italic in lieu of a "visited link color." If so, I think you should refer to it specifically as "font style" because style in a css file can include color. In any case, the current sentence is too ambiguous. editorial EO36 [@@ done] Accept proposal  
A 1.3.1 Highlighted Items EO37: (Implementing) missing word: Second sentence: "they working" should be "they are working" editorial EO37 [@@ done] Accept proposal  
A 1.3.1 Highlighted Items EO38 (Implementing) Should "hover" be included in the list of 1.3.1 classes where highlighting is user controlled? Or would this be the same as "selection"? substantive

EO38 [@@done]
UAWG decided changing the highlighting of recognized enabled input elements will cover most of the cases where things are hoverable, and the remainder are edge cases.

Proposal not accepted  
A 1.3.1 Highlighted Items EO29.2: (Implementing) SC 1.3.1 has three notes. I wonder if it is worth numbering them in note 1, note 2 ... or may be it does not make sense? editorial EO29.2 [@@ done] Accept proposal  
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) (a) foreground colors, (b) background colors, and (c) borders (configurable color, style, and thickness)

EO33: (Implementing) more white space is needed above Section 1.3.2 and now that I'm looking at this more closely, greater line space is needed throughout between paragraphs and bullet items and above subheadings.



EO33: [@@ done]



Accept proposal  
AA 1.3.2 Highlighting Options OCAD8: This seems like too much configurability, especially if the user agent developer has chosen highlighting styling to maximize visibility within the widest variety of content situations. Fluid UIOptions for example enlarges input fields and makes images underlined and bold. substantive OCAD8 [@@done] UAWG decided even though many UA developers may think they have chosen a good default highlighting option, there will be users who will require further customization. Proposal not accepted  
Guideline 1.4 - Provide text configuration.          
Summary: The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2).

EO39: Typo: not sure whether we should indicate them in EOWG comments: Summary contains one word "the" that should not be there:

"The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2)."
editorial [@@done] Accept proposal  
A 1.4.1 Configure Rendered Text: The user can globally set any or all of the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults: (Level A) (a) text scale (the general size of text) (b) font family (c) text color (foreground and background) (d) line spacing (e) character spacing          
A 1.4.2 Preserving Size Distinctions: The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. headers continue to be larger than body text). (Level A)          
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 independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. (Level A) OCAD51: Seems like a lot for A. Maybe AA. substantive OCAD51: [@@ done] [survey] set to AA Accept proposal  
Guideline 1.6 - Provide synthesized speech configuration. AS1 there should be a section in 1.6 covering the ability to quickly and easily switch speech synthesis language. (http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Jun/0000.html for proposal) substantive [@@ done] Group agreed to add 1.6.5 Accept proposal  
Summary: If synthesized speech is produced, the user can specify speech rate and volume (1.6.1), pitch and pitch range (1.6.2), and synthesizer speech characteristics like emphasis (1.6.3) and features like spelling (1.6.4). EO40: grammar/style: "and synthesizer speech characteristics like emphasis (1.6.3) and features like spelling (1.6.4)." "like" should be replaced with "such as" if meaning here includes features such as "emphasis" and "spelling". If the features are similar to "emphasis" and "spelling" but different, then "like" would be used editorial [@@ done] Accept proposal  
A 1.6.1 Speech Rate, Volume, and Voice: If synthesized speech is produced, the user can specify the following: (Level A) (a) speech rate, (b) speech volume (independently of other sources of audio), and (c) voice, when more than one voice option 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) (a) pitch (average frequency of the speaking voice), and (b)  pitch range (variation in average frequency)          
Note: Because the technical implementations of text to speech engines vary (e.g., formant-based synthesis or concatenative synthesis), a specific engine may not support varying pitch or pitch range. A user agent will expose the availability of pitch and pitch range control if the currently selected or installed text to speech engine offers this capability.          
AAA 1.6.3 Advanced Speech Characteristics: The user can adjust all of the speech characteristics offered 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) (a) user-defined extensions to the synthesized speech dictionary, (b) "spell-out", where text is spelled one character at a time, or according to language-dependent pronunciation rules, (c) 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), (d) at least two ways of speaking punctuation: spoken literally, and with punctuation understood from natural pauses.          
Guideline 1.7 - Enable Configuration of User Stylesheets.          
Summary: The user agent shall support user stylesheets (1.7.1) and the user can choose which if any user-supplied (1.7.2) and author-supplied (1.7.3) stylesheets to use. The user agent will allow users to save user stylesheets (1.7.4).

EO41: (Implementing) 3rd bullet under "Examples of Success Criterion". 2nd occurrence of word "text" should be removed.



editorial [@@done]



Accept proposal  
Summary 1.7 EO42: (Implementing) similar problem with 4th bullet under "Examples of Success Criterion". "text easiest to read text if text is highlighted" should be changed to: "text easiest to read if it is highlighted" editorial [@@done] Accept proposal  
A 1.7.1 Support User Stylesheets: If the user agent supports a mechanism for authors to supply stylesheets, the user agent also provides a mechanism for users to supply stylesheets. (Level A)

EO43: (Implementing) I wonder if it would be useful to explain acronyms such as in last "Examples of Success Criterion 1.7.1, 1.7.2 & 1.7.3".

"Mattias has ADHD and finds text easiest to read text·...

explain what is ADHD? Is it clear to any reader?


editorial [@@done] Accept proposal  
A 1.7.2 Apply User Stylesheets: If user style sheets are supported, then the user can enable or disable user stylesheets for: (Level A) (a) all pages on specified websites, or (b) all pages          
A 1.7.3 Author Style Sheets: If the user agent supports a mechanism for authors to supply stylesheets, the user can disable the use of author style sheets on the current page. (Level A)          
AA 1.7.4 Save Copies of Stylesheets: The user can save copies of the stylesheets referenced by the current page, in order to edit and load the copies as user stylesheets. (Level AA)          
Guideline 1.8 - Help users to use and orient within windows and viewports. EO45: The meaning of this heading in not clear. Does "use" refer to "windows & viewport" as in "help users to use windows and viewports"? Suggest something like "Help users to orient within, and control, windows and viewports" editorial [@@ done] part of the Stem rewrite Accept Proposal  
Summary: The user agent provides programmatic and visual cues to keep the user oriented. These include highlighting the viewport (1.8.1), keeping the focus within the viewport (1.8.2 & 1.8.7), resizing the viewport (1.8.3), providing scrollbar(s) that identify when content is outside the visible region (1.8.4) and which portion is visible (1.8.5), changing the size of graphical content with zoom (1.8.6 & 1.8.12), restoring the focus and point of regard when the user returns to a previously viewed page (1.8.8). Users can set a preference whether new windows or tabs open automatically (1.8.9) or get focus automatically (1.8.10). Additionally, the user can specify that all view ports have the same user interface elements (1.8.11), if and how new viewports open (1.8.9), and whether the new window automatically gets focus (1.8.10). The user can mark items in a webpage and use shortcuts to navigate back to marked items. (1.8.13).

EO44: Summary is long on this item. Readability would be improved if it was broken up into bullet items.

editorial EO44: Editors did not want to change the style of Summaries for this one summary. [@@ done] Proposal not accepted  
A 1.8.1 Highlight Viewport: The viewport with the input focus is highlighted and the user can customize attributes of the highlighting mechanism (e.g. shape, size, stroke width, color, blink rate). The viewport can include nested viewports and containers. (Level A) OCAD9: Maybe highlighting customization part should be AA? substantive OCAD9:[@@ done][survey] UAWG decided to remove highlighting from 1.8.1 and add a new SC with highlighting at AA. Accept proposal  
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 Resize Viewport: The user can resize graphical viewports within the limits of the display, overriding any values specified by the author. (Level A) OCAD10: Maybe AA? I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? substantive OCAD10: [@@ done] [survey] Action-862 OCAD10: proposal accepted  
A 1.8.4 Viewport Scrollbars: When the rendered content extends beyond the viewport dimensions, users can have graphical viewports include scrollbars, overriding any values specified by the author. (Level A)          
A 1.8.5 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level A) AS2 (Implementing) 1.8.5 and 1.8.6 have the same $$Ally text and they should be slightly different editorial [@@ done] deleted the duplicate. Alternative Action  
A 1.8.6: Zoom: The user can rescale content within graphical viewports as follows: (Level A) (a) Zoom in: to at least 500% of the default size; and (b) Zoom out: to at least 10% of the default size, so the content fits within the height or width of the viewport. OCAD11: I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? substantive

OCAD11: [@@ done][survey] reword

finalized rewording for top-level viewport

Accept proposal  
A 1.8.7 Maintain point of regard: To the extent possible, the point of regard remains visible and at the same location within the viewport when the viewport is resized, when content is zoomed or scaled, or when content formatting is changed. (Level A)          
AA 1.8.8 Viewport History: For user agents that implement a viewport history mechanism (e.g. "back" button), the user can return to any state in the viewport history that is allowed by the content, including a restored point of regard, input focus and selection. (Level AA)

EO46: In "Examples of Success Criteria 1.8.8, 1.8.9 & 1.8.10:", first example talking about Justin, there is a word repetition: "The word remains selected remains the same so he doesn't have to reorient or find it on the page."
Second example talks about George who uses a screen reader. In other examples, the text talks about Jorge, not sure if this is the same person as the names are written differently.



EO46 [@@ done] fixed word repetition. George and Jorge are different people.





Partial accept  
AA 1.8.8 Viewport History OCAD12: I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? Wording if we should group together top-level viewport SCs for clarity. substantive OCAD12 [@@done] [proposal] Accept proposal  
AA 1.8.9 Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA)          
AA 1.8.10 Do Not Take Focus: If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open. (Level AA)          
AA 1.8.11 Same UI: 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.12 Reflowing Zoom: The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA) OCAD13: usual wording is specify rather than "request". BTW all of the "specifies" make it sound like a lot of settings are required....could some be rewritten in the form: "When reflowable content in a graphical viewport is rescaled, it can be reflowed so that one dimension of the content fits within the height or width of the viewport." substantive OCAD13: [@@ done] [survey] Action-863 Accept proposal  
Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap).          
AAA 1.8.13 Webpage Bookmarks: The user can mark items in a webpage, then use shortcuts to navigate back to marked items. The user can specify whether a navigation mark disappears after a session, or is persistent across sessions. (Level AAA)          
Guideline 1.9 - Provide alternative views.          
Summary: The user can view the source of content (1.9.2), or an outline view of important elements. (1.9.1). EO47: For 1.9 should "or" in header ("The user can view the source of content (1.9.2), or an outline view of important elements. (1.9.1).") be "and/or" or simply "and"? Current wording seems to imply you should only do one or the other. editorial EO47 [@@ done] Accept proposal  
AA 1.9.1 Outline View: Users can view a navigable outline of rendered content composed of labels for important elements, and can move focus efficiently to these elements in the main viewport. (Level AA)          
Note: The important elements depend on the web content technology, but may include headings, table captions, and content sections.          
AAA 1.9.2 Source View: The user can view all source text that is available to the user agent. (Level AAA)

EO48: (Implementing) The examples of Success Criterion 1.9.2 talk about users who display the source code of a page to find out what an untagged image is for or to modify style sheets. I am not sure that these examples are realistic as users need to have knowledge of code to have a look at lines of source codes. Either the group should explain that these users have already good knowledge of page coding, or the examples should be rewritten. @@Eowg thoughts on this are welcome. See for example the users' reactions in Jaws 14 who can set their screen reader to start reading on a specific place (h, div, and so on) on the page or ignore iframes (like facebook iframes). They are disturbed by the use of code to set this.

editorial EO48 [@@done] Editors added that George is a web developer and uses source view as a last resort. Partial accepted  
Guideline 1.10 - Provide element information.          
Summary:The user agent presents information about content relationships (e.g. form labels, table headers)(1.10.1), and extended link information (e.g. title, internal vs. external) (1.10.2) EO50: I know what you're saying in the summary but I wonder if there's a better phrase than "content relationship" - perhaps "content hierarchy" or "content metadata" or "parent/sibling relationships." editorial [@@ done] Editors changed to "relationships between elements"    
AA 1.10.1 Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA) EO49 (Implementing) Same comment as EO48 for example of success criterion 1.10.2, where the user "selects the text he's interested in, opens the browser's debug window, which shows him that the selected text is an element with class "story" inside a paragraph inside a DIV with class "Premiere". He then knows the combination of classes and element types to specify in the user style sheet.". editorial [@@done Editors added that Jack frequently uses user stylesheets.    
AAA 1.10.2 Access to 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) OCAD14: This one say "can determine". Same as "can access"? editorial [@@done] Editors changed the handle to "Show". Access implies more interactivity that determining. Alternative action taken  
PRINCIPLE 2. Ensure that the user interface is operable          
Guideline 2.1 - Ensure full keyboard access.          
Summary: Users can operate all functions (2.1.1), and move focus (2.1.2) using just the keyboard. Users can activate important or common features with shortcut keys, (2.1.6), override keyboard shortcuts in content and user interface (2.1.4), escape keyboard traps (2.1.3), specify that selecting an item in a dropdown list or menu not activate that item or move to that new web page (2.1.4) and use standard keys for that platform (2.1.5).          
A 2.1.1 Keyboard Operation: All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A)          
A : Every viewport has an active or inactive keyboard focus at all times. (Level A)

EO51 (Implementing) example 1: Two names have been used for first example: Amal and Alan.



[@@t done] Editors fixed


A 2.1.2 Keyboard Focus OCAD15: Is this still needed with 1.8.1 and 1.8.8? substantive OCAD 15: [@@ done] [proposal] UAWG decided not to accept because 2.1.2 requires a keyboard focus to exist, and the others are "if a keyboard focus exists". Proposal not accepted  
A 2.1.3 No Keyboard Trap: 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 other standard exit methods), 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 content. (Level A)

EO52 (Implementing) last example refers to a specific device and screeen reader (Iphone and Voiceover). Is it ok to do that, or should the document remain device and screen reader neutral?

"Ari uses Voiceover on his iPhone to navigate a webpage. He selects an item and is able to activate the element using gestures. This requires sufficient screen real estate to perform gestures without changing focus."
editorial EO52: [@@ done] Accepted proposal  
  2.1.4 Separate Selection from Activation OCAD16: Does "author content" need a definition? Sometimes also says "author supplied" question OCAD16 [@@ done] [proposal] UAWG decided to change it to author-supplied Accepted proposal  
A 2.1.5 Follow Text Keyboard Conventions: The user agent follows keyboard conventions for the operating environment. (Level A)          
A 2.1.6 Efficient Keyboard Access: The user agent user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level A)          
Guideline 2.2 - Provide sequential navigation          
Summary: Users can use the keyboard to navigate sequentially (2.2.3) to all the operable elements (2.2.1) in the viewport as well as between viewports (2.2.2). Users can optionally disable wrapping or request a signal when wrapping occurs (2.2.4).          
A 2.2.1 Sequential Navigation Between Elements: The user can move the keyboard focus backwards and forwards through all recognized enabled elements in the current viewport. (Level A)          
A 2.2.2 Sequential Navigation Between Viewports: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A)          
A 2.2.3 Default Navigation Order: If the author has not specified a navigation order, the default sequential navigation order is the document order. (Level A)          
A 2.2.4 Options for Wrapping in Navigation The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can request notification when such wrapping occurs. (Level AA) OCAD17: Should this be AA? Missing ":". Also, wording feels odd (allow it to be turned off, alert when it is done).  

[editorial] [@@ done]

[survey] A-> AA [@@ done]

stay at AA, reword

Guideline 2.3 - Provide direct navigation and activation          
Summary: Users can navigate directly (e.g. keyboard shortcuts) to important elements (2.3.1) with the option of immediate activation of the operable elements (2.3.3). Display commands with the elements to make it easier for users to discover the commands (2.3.2 & 2.3.4). The user can remap and save direct commands (2.3.5).          
AA 2.3.1 Direct Navigation to Important Elements: The user can navigate directly to any important elements (e.g. structural or operable) in rendered content. (Level AA) OCAD18: Maybe remove "any" and the e.g....it is really important the reader views the definition. editorial [@@done] Editors removed "any" and e.g. Accepted proposal  
AA 2.3.2 Present Direct Commands from Rendered Content (enhanced): The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email). (Level AA) OCAD19: Says "Enhanced" but there is no minimum. Prefer to have just one e.g. per sentence rather than two. editorial [@@ done] UAWG removed Enhanced. Both examples are needed for clarity. Partial  
A 2.3.3 Direct activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A) OCAD20: Perhaps AA? substantive [survey] proposal not accepted. [@@ done] the UAWG feels this is essential for users relying on speech input, and there are numerous examples available. Not Accepted  
AA 2.3.4 Present Direct Commands in User Interface: The user can have any direct commands in the user agent user interface (e.g. keyboard shortcuts) be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) OCAD21: Again, prefer just one e.g. editorial [@@ done] Both e.g. are needed for clarity. Not Accepted  
AA 2.3.5 Customize Keyboard Commands: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. The user must be able to save these settings beyond the current session. (Level AA) OCAD22: Save requirement should be removed as it is covered by 2.7.1. Also the single-key and key-plus-modifier text seems like overkill. substantive OCAD22 [@@ done][proposal] UAWG decided to remove Save and note it in the IER. Accepted  
Guideline 2.4 - Provide text search.          
Summary: Users can search rendered content (2.4.1) forward or backward (2.4.2) and can have the matched content highlighted in the viewport (2.4.3). The user is notified if there is no match (2.4.4). Users can also search by case and for text within alternative content (2.4.5).          
A 2.4.1 Text Search: The user can perform a search within rendered content (e.g. not hidden with a style), including rendered text alternatives and rendered generated content, for any sequence of printing characters from the document character set. (Level A) EO53 (Implementing) In "Examples of Success Criterion 2.4.1:"
  • Example 2: "Betty, who has low vision, is attempting to create a user stylesheet for a site. She need to know", instead of "she needs to know".
  • 5th example: "Agnes uses the search function to seach through the captions": write search through the captions.

OCAD23: Can e.g. be removed?








[@@ done] corrected





[@@ done] Editors agreed that the e.g. added ambiguity.







A 2.4.2 Find 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) EO54 (Implementing) In Examples of Success Criterion 2.4.3: "Jules is low vision and uses a magnified screen." Better write: "Jules has low vision and uses a magnified screen." editorial [@@ done] fixed Accepted  
A 2.4.4 Alert on Wrap or No Match: The user can be notified when there is no match to a search operation. The user can be notified when the search continues from the beginning or end of content. (Level A)          
AA 2.4.5 Search alternative content: The user can perform text searches within textual alternative content (e.g. text alternatives for non-text content, captions) even when the textual alternative content is not rendered onscreen. (Level AA)          
Guideline 2.5 - Provide structural navigation.          
Summary: Users can view (2.5.1), navigate (2.5.2), and configure the elements used in navigating (2.5.3) content hierarchy.          
AA 2.5.1 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) OCAD24: How is this related to 1.10.2? question OCAD 24 [@@ done] [proposal] The reference to 2.5.2 was deleted Accepted proposal Accepted
AA 2.5.2 Navigate by structural element: The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA) (a) by heading (b) within tables

OCAD25: How is this related to 1.10.1?

AS3 (Implementing) has "inpu" which should be "input"




OCAD25 [@@ done][proposal] The reference to 2.5.2 was deleted


Accepted proposal Accepted
AAA 2.5.3 Configure Elements for Structural Navigation: The user can configure sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA) OCAD26: "configure sets of" implies ability to create multiple sets substantive OCAD 26 [@@ done][proposal] UAWG decided to change to "a set" Accepted proposal Accepted
Guideline 2.6 - Provide access to event handlers          
Summary:Users can interact with web content by mouse, keyboard, voice input, gesture, or a combination of input methods. Users can discover what event handlers (e.g. onmouseover) are available at the element and activate an element's events individually (2.6.1).          
AA 2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner. (Level AA) OCAD27: User can discover? substantive OCAD27 [@@ done][proposal] UAWG decided to reword the SC. Accepted  
Guideline 2.7 - Configure and store preference settings          
Summary: Users can restore preference settings to default (2.7.2), and accessibility settings persist between sessions (2.7.1). Users can manage multiple sets of preference settings (2.7.3), and adjust preference setting outside the user interface so the current user interface does not prevent access (2.7.4). It's also recommended that groups of settings can be transported to compatible systems (2.7.5).          
A 2.7.1 Persistent Accessibility Settings: User agent accessibility preference settings persist between sessions. (Level A) OCAD28: Maybe reword to use the term "saved" editorial [@@ done] Saving is in 2.7.3 Not Accepted  
A 2.7.2 Restore all to default: The user can restore all preference settings to default values. (Level A)          
AA 2.7.3 Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA) EO55 (Implementing) In last example of SC 2.7.3: "At those times he users his browser's user preference profiles to load a different configuration that’s optimized for the keyboard." Write: "He uses his keyboard" editorial [@@ done] Accepted  
AA 2.7.4 Change preference settings outside the user interface: The user can adjust any preference settings required to meet the User Agent Accessibility Guidelines (UAAG) 2.0 from outside the user agent user interface. (Level AA)

OCAD29: AAA perhaps?





[survey] [@@ done] UAWG decision






AA 2.7.4 Change preference settings outside the user interface:

EO56 (Implementing)

  • In Intent of SC 2.7.4 the following sentence repeats a word twice and is not understandable to me: "The user agent can accomplish this in multiple including including detecting and implementing the platform accessibility settings, providing an external file to modify, providing access to settings from a separate utility program, providing accessibility options in the installation program, or providing command-line switches to change the user agent's behavior." {Sylvie, 17 June}
  • In the 4th example of SC 2.7.4, there seems to be a word missing: "Justin has an attention deficit disorder. He is setting up his new e-book reader and is interrupted while setting the default font colors, then finds he accidentally set his background and font color to white on white.
editorial EO56 [@@ done] Accepted  
AAA 2.7.5 Portable Preference Settings: The user can transfer all compatible user agent preference settings between computers. (Level AAA) OCAD30: "computers" sounds outdated. editorial

[@@ done]


Guideline 2.8 - Customize display of GUI controls          
Summary: It's recommended that users can add, remove and configure the position of graphical user agent controls and restore them to their default settings (2.8.1).          
AA 2.8.1 Customize display of controls representing user interface commands, functions, and extensions: The user can customize which user agent commands, functions, and extensions are displayed within the user agent's user interface as follows:(Level AA) (a) 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. (b) Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some control). (c) 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). (d) Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls. (e) Reset: The user has the option to reset the containers and controls to their original configuration. EO57 (Implementing) In Examples for SC 2.8.1:
  • Third example about Caraway: "In programs she uses a lot she removes toolbars that she doesn't use in order to reduce the probably that the speech program will interpret text input as a toolbar command and click something Caraway does not intend." May be they mean probability?
  • Last example about Jennifer: "she turns on the built-in voice application so she can quickly find her way around Linda's phone." So she is repeated twice.



EO57 [@@ done]







AA 2.8.1 Customize display of controls representing user interface commands, functions, and extensions: OCAD31: This SC is probably twice as long as the next biggest. Has a different feel. substantive OCAD31 [@@ done] [proposal] UAWG decided that this SC had been many SC. They were combined because they all interrelated and built upon each other. Proposal not accepted Accepted
AA 2.8.2 Reset Toolbar Configuration:

EO58 there is only one title of 2.8.2 reset Toolbar configuration, and no text in it.


editorial EO58 [@@ done] Accepted  
AA 2.8.2 Reset Toolbar Configuration: OCAD32 this is an orphan handle editorial OCAD32 [@@ done] Accepted  

Guideline 2.9 - Allow time-independent interaction.

Summary: Users can extend the time limit for user input when such limits are controllable by the user agent (2.9.1); by default, the user agent shows the progress of content in the process of downloading (2.9.2).          
A 2.9.1 Adjustable Timing: Where time limits for user input are recognized and controllable by the user agent, the user can extend the time limits. (Level A)          
A 2.9.2 Retrieval Progress: By default, the user agent shows the progress of content retrieval. (Level A) OCAD33: I think this is in the wrong GL, it doesn't allow time-independent interaction substantive OCAD33 [proposal] UAWG decided to move it to 3.2.6 Avoid mistakes. Added a new example of an RSI user. Changed progress of content retrieval to content retrieval activity Accept proposal Accept
Guideline 2.10 - Help users avoid flashing that could cause seizures.          
Summary: To help users avoid seizures, the default configuration prevents the browser user interface and rendered content from flashing more than three times a second above a luminescence or color threshold (2.10.1), or does not flash at all (2.10.2).          
A 2.10.1 Three Flashes or Below Threshold: In its default configuration, the user agent does not display any user interface components or recognized content that flashes more than three times in any one-second period, unless the flash is below the general flash and red flash thresholds. (Level A) OCAD34: This is good for the User Agent UI, but hard to automatically determine in playing content. Perhaps 2.11.1 handles this? substantive OCAD34 [@@ done] [proposal] UAWG decided to remove the "or recognized content" Accepted proposal  
AAA 2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components or recognized content 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) OCAD35: Could this also then be removed? (related to comment OCAD34) substantive OCAD35 [@@ done] [see OCAD34]] [proposal] UAWG decided to remove the "or recognized content" Accepted proposal  
Guideline 2.11 - Provide control of content that may reduce accessibility.          
Summary: The user can present placeholders for time-based media (2.11.1) and executable regions (2.11.2), or block all executable content (2.11.3); adjust playback (2.11.4), stop/pause/resume (2.11.5), navigate, (2.11.6) and specify tracks for prerecorded time-based media (2.11.8); and adjust contrast and brightness of visual time-based media (2.11.9).          
Applicability Notes: Guideline 2.11 and its success criteria only apply to images, animations, video, audio, etc. that the user agent can recognize.          
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)

EO59 (Implementing) In the first examples of Success Criterion 2.11.1: one word repeated: "Jill is blind. She browses browses the web using a screen reader to listen to the text of web pages."

editorial EO59 [@@ done] Accepted  
A 2.11.2 Execution Placeholder: The user can render a placeholder instead of executable content that would normally be contained within an on-screen area (e.g. Applet, Flash), until explicit user request to execute. (Level A)

EO 60 (Implementing) In Intent of Success Criterion 2.11.2 : last sentence of the note before examples: placholder instead of placeholder.



EO60 [@@ done]





A 2.11.2 Execution Placeholder

EO 61 (Implementing) Examples of SC 2.11.2:

  • second example word repetition: "When he is ready to he is ready to hear it, he navigates to the placeholder".
  • third example, a sentence that is not easy to understand: "Evan has configured his mobile phone to so any audio or video file displays a placeholder with a triangle "play" icon."
editorial EO61 [@@ done] removed duplicates, and removed stray word that confused the grammar. Accepted  
A 2.11.3 Execution Toggle: The user can turn on/off the execution of executable content that would not normally be contained within a particular area (e.g. Javascript). (Level A)          
A 2.11.4 Playback Rate Adjustment 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 A) (a) The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time. (b) Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality. (c) Audio and video tracks remain synchronized across this required range of playback rates. (d) The user agent provides a function that resets the playback rate to normal (100%). OCAD36: Could this be AA? substantive OCAD36 [@@ done] [survey]Proposal Accepted change to AA Accepted  
A 2.11.5 Stop/Pause/Resume Time-Based Media: The user can stop, pause, and resume rendered audio and animation content (including video, animated images, and changing text) that last three or more seconds at their default playback rate. (Level A) OCAD37: 3 seconds seems weirdly short substantive OCAD37 [@@ done]Taken from WCAG wording. No change. Not accepted Accepted
A 2.11.6 Navigate Time-Based Media: The user can navigate along the timebase using a continuous scale, and by relative time units within rendered audio and animations (including video and animated images) that last three or more seconds at their default playback rate. (Level A) OCAD38: 3 seconds seems weirdly short substantive [@@ done]Taken from WCAG wording. No change. Not accepted Accepted
AA 2.11.7 Semantic Navigation of Time-Based Media: The user can navigate by semantic structure within the time-based media, such as by chapters or scenes present in the media. (Level AA)          
AA 2.11.8 Track Enable/Disable of Time-Based Media: During time-based media playback, the user can determine which tracks are available and select or deselect tracks, overriding global default settings, such as captions or audio descriptions. (Level AA) OCAD39: Both the examples in the implementing document are taken care of by something in GL1.1? So perhaps this can be removed. substantive OCAD39 [@@ done] [proposal] UAWG decided to delete 2.11.8 and move the intent and examples to 1.1.1. New example to add to 1.5.1 Accepted proposal  
AAA 2.11.9 Video Contrast and Brightness: Users can adjust the contrast and brightness of visual time-based media. (Level AAA)          
Guideline 2.12 - Other Input Devices          
Summary: For all input devices supported by the platform, the user agents should let the user perform all functions aside from entering text (2.12.2), and enter text with any platform-provided features (2.12.1). If possible, it is also encouraged to let the user enter text even if the platform does not provide such a feature (2.12.3).          
A 2.12.1 Support Platform Text Input Devices: If the platform supports text input using an input device, the user agent is compatible with this functionality. (Level A)          
AA 2.12.2 Operation With Any Device: If an input device is supported by the platform, all user agent functionality other than text input can be operated using that device. (Level AA)          
AAA 2.12.3 Text Input With Any Device: If an input device is supported by the platform, all user agent functionality including text input can be operated using that device. (Level AAA)          
PRINCIPLE 3: Ensure that the user interface is understandable          
Guideline 3.1 - Help users avoid unnecessary messages.          
Summary: Users can turn off non-essential messages from the author or user-agent.          
AA 3.1.1 Reduce Interruptions: The user can avoid or defer recognized non-essential or low priority messages and updating/changing information in the user agent user interface and rendered content. (Level AA) OCAD40: Maybe remove "and rendered content". Only mechanism for this in content would seem to be politeness level and implementing that is should following the content spec. substantive OCAD40 [@@ done][survey] Alternative action taken Alternative action taken Accepted
Guideline 3.2 - Help users avoid and correct mistakes.          
Summary: Users can have form submissions require confirmation (3.2.1), go back after navigating (3.2.2), and have their text checked for spelling errors (3.2.3).          
AA 3.2.1 Form Submission: The user can specify whether or not recognized form submissions must be confirmed. (Level AA)          
AA 3.2.2 Back Button: The user can reverse recognized navigation between web addresses (e.g. standard "back button" functionality). (Level AA)          
AA 3.2.3 Provide spell checking functionality: User agents provide spell checking functionality for text created inside the user agent. (Level AA)          
A 3.2.4 Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A)          
Note: Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer.          
A 3.2.5 Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A)          
Guideline 3.3 - Document the user agent user interface including accessibility features.          
Summary: User documentation is available in an accessible format (3.3.1), it includes accessibility features (3.3.2), delineates differences between versions (3.3.3), provides a centralized views of conformance UAAG2.0 (3.3.4), and is available as context sensitive help in the UA (3.3.5).          
A 3.3.1 Accessible documentation: The product documentation is available in a format that meets success criteria of WCAG 2.0 Level "A" or greater. (Level A) OCAD41: "conforms to least WCAG 2.0 Level A. editorial OCAD41 [@@done] Accepted  
A 3.3.2 Document Accessibility Features: All features of the user agent that meet User Agent Accessibility Guidelines 2.0 success criteria are documented. (Level A) OCAD42: The corresponding ATAG2 SC was rewritten: http://www.w3.org/WAI/AU/ATAG20/#sc_a421 substantive OCAD42 [@@ not done]    
AA 3.3.3 Changes Between Versions: Changes to features that meet UAAG 2.0 success criteria since the previous user agent release are documented. (Level AA)          
AAA 3.3.4 Centralized View: There is a dedicated section of the documentation that presents a view of all features of the user agent necessary to meet the requirements of User Agent Accessibility Guidelines 2.0. (Level AAA)          
Guideline 3.4 - The user agent must behave in a predictable fashion.          
Summary: Users can prevent non-requested focus changes (3.4.1).          
A 3.4.1 Avoid unpredictable focus: The user can prevent focus changes that are not a result of explicit user request. (Level A) OCAD43: This seems like the superset (and so the possible replacement) of 1.8.9 and 2.1.4. substantive OCAD43 [@@ done][proposal] UAWG decided 1.8.9 is separate enough. 2.1.4 is separate. They are needed where they are. Proposal Not Accepted May bring another proposal
PRINCIPLE 4: Facilitate programmatic access          
Guideline 4.1 - Facilitate programmatic access to assistive technology          
Summary: Be compatible with assistive technologies by supporting platform standards (4.1.1), including providing information about all menus, buttons, dialogs, etc. (4.1.2, 4.1.6), access to DOMs (4.1.4), and access to structural relationships and meanings, such as what text or image labels a control or serves as a heading (4.1.5). 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). Make sure that that programmatic exchanges are quick and responsive (4.1.7).          
A 4.1.1 Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A)          
A 4.1.2 Name, Role, State, Value, Description: For all user interface components including user interface, rendered content, generated content, and alternative content, the user agent makes available the name, role, state, value, and description via platform accessibility services. (Level A) OCAD44: Isn't this implementation detail for 4.1.1? substantive OCAD44 [@@ done]

[survey] UAWG decided that leaving them separate success criteria provides more protection for assistive technology


Proposal Not Accepted Accepted
A 4.1.3 Accessible Alternative: If a component of the user agent user interface cannot be exposed through platform accessibility services, then the user agent provides an equivalent alternative that is exposed through the platform accessibility service. (Level A)          
A 4.1.4 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (Level A)          
A 4.1.5 Write Access: 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 available programmatically. (Level A) OCAD45: Still isn't possible for ARIA as far as I know. substantive OCAD45 [@@ done] [proposal] UAWG decided that the general requirement is still true. Scripts must be properly notified by the browser when states change. Proposal not accepted Accepted
A 4.1.6 Expose Accessible Properties: If any of the following properties are supported by the platform accessibility services, make the properties available to the accessibility platform architecture: (Level A) (a) the bounding dimensions and coordinates of onscreen elements (b) font family of text (c) font size of text (d) foreground color of text (e) background color of text. (f) change state/value notifications (g) selection (h) highlighting (i) input device focus (j) direct keyboard commands (k) underline of menu items (keyboard command/shortcuts) OCAD46: Why is this split from 4.1.2? question

OCAD46 [@@ done][ proposal]
UAWG discussed combining 4.1.2 and 4.1.6, but 4.1.6 needed the IF statement. 4.1.2 and 4.1.6 were rewritten to clarify them.

Alternative Action Accepted
A 4.1.7 Timely Communication: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A)          
PRINCIPLE 5: Comply with applicable specifications and conventions          
Guideline 5.1 - Comply with applicable specifications and conventions.          
Summary: When the browser's menus, buttons, dialogs, etc. are authored in HTML or similar standards, they need to meet W3C's Web Content Accessibility Guidelines.          
AAA 5.1.1 WCAG Compliant: Web-based user agent user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level AAA) OCAD47: Might want to remove Level AAA since it will be hard to find implementations. substantive OCAD51 [@@ done][survey] Proposal not accepted because the group felt it was too early to remove SC for lack of implementations. Proposal not accepted  
Note: This success criterion does not apply to non-Web-based user agent user interfaces, but does include any parts of non-Web-based user agents that are Web-based (e.g. help systems).          
A 5.1.2 Implement accessibility features of content specs: Implement and cite in the conformance claim the accessibility features of content specifications. Accessibility features are those that are either (Level A): (a) Identified as such in the specification or (b) Allow authors to satisfy a requirement of WCAG OCAD48: This is central to the whole thing and it seems buried here. substantive OCAD48 [@@ done]The group discussed renumbering or adding to the intro to make it more promintent, but it conflicted with other priorities (parallel to WCAG). Proposal Not accepted Accepted
A 5.1.3 Implement Accessibility Features of platform: If the user agent contains non-web-based user interfaces, then those user interfaces follow user interface accessibility guidelines for the platform. (Level A)          
A 5.1.4 Handle Unrendered Technologies: If the user agent does not render a technology, the user can choose a way to handle content in that technology (e.g. by launching another application or by saving it to disk). (Level A) OCAD49: Is this an accessibility issue? question OCAD49 [@@ done] [survey] proposal accepted. SC removed Accepted  
AA 5.1.5 Alternative content handlers: The user can select content elements and have them rendered in alternative viewers. (Level AA) OCAD50: Why is this AA if this user agent does a good job of making them accessible? question OCAD50 [@@ done] [followup] explain no change Not accepted  
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)          
Applicability Note: 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.