WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
Site Navigation: W3C Home > WAI Home > UAWG Home
This is a working document from the User Agent Accessibility Guidelines Working Group (UAWG) that details action taken on the 102 issues received from 12 commenters on the Last Call working drafts of 7 November 2013 of UAAG 2.0 and Implementing UAAG 2.0. The table includes relevent text from UAAG 2.0 and Implementing UAAG 2.0; the classification of the comment, the UAWG response, and whether the commenter agreed with the change. There may also be highlighted text in the Response column whether or not the change has been accepted into the latest Editors' Draft. 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
| Priority | Whole Line | Comments | Response | Disposition | type | Acknowledgment |
|---|---|---|---|---|---|---|
General Comments |
||||||
| General Comments | CR01: Chrome has a general philosophy that users should not be presented with too many settings or switches to control. Settings that are only enabled by a small minority of users increase the perceived complexity for everyone else and also increase the number of possible configurations for the developer to support and test. We prefer many such features to be available via extensions or add-ons instead. This document contains a large number of recommendations for additional configurations a user can specify, presumably via a specific option or setting built-into the browser. What do you think about having extensions available for each of these features, rather than building them into the browser? Would Chrome be considered compliant with this spec if we implemented all of these guidelines as extensions and published an easy-to-use catalog of these for users to browse and install the ones they want? The "Implementing" spec even references Firefox add-ons, like Text Equivalent Expand Abbreviations. Do the spec authors feel that such features should be built into the browser, or merely that such an option must be available to users? |
[done] UAWG adjusted the wording of the conformance section to specifically allow extensions. In order to claim compliance, the claimant must demonstrate that solutions, and any required additional components, are available to non-expert users. Enabling the creation of such solutions is not by itself sufficient. UAWG also edited the Introduction to highlight using extensions. |
Accept | substantive | ||
| General Comments | CR03: Some of the recommendations seem overly technical and narrow: for example, the use-case for Show Element Hierarchy is that a user might want to write a custom stylesheet and needs to determine the path to a particular element within a page to write a style rule for it. However, there are already more innovative solutions to this problem available. A popular Chrome extension, StyleBot, lets the user simply click on any element on the page and modify the custom stylesheet with a friendly dialog interface. They can explore the classes that this element belongs to and apply the same style change to all elements in that class. My concern is just that these guidelines should not specify one narrow solution to a problem that precludes a more clever implementation. | [done] UAWG thinks it is true that some of the success criteria have very technical and narrow requirements, and that other, more effective approaches to addressing the problems may be developed. However, we do not believe that requiring the base-level fallback feature discourages development or inclusion of more effective approaches. (It's also true that there are additional use cases for this feature, such as a user of assistive technology that wants their screen reader to notify them when a region of the document changes, or when they want to set up shortcuts that move focus or a magnifying window between specific locations.) | Partial accept | substantive | ||
| General Comments | CR04: Many of the guidelines are specific to a desktop computer, and written in a way that's too narrow to apply to a web browser running on a phone, tablet, or other device that may not have a keyboard. The guidelines should be written in a way that explain the user need and don't assume that a keyboard is available. | [done] UAWG entirely agrees; any success criterion that relies on a physical keyboard, visual output, or other platform dependencies should be scoped in its own language. Please let us know of any success criteria that don't sufficiently address this. Please keep in mind that even devices without physical keyboards are expected to support keyboard emulators and other types of assistive technology that rely on keyboard emulation at the programming interface level. See the note added to Principle 2 and the updated definition of "keyboard interface". | Accept | substantive | ||
| General Comments | CR05: Many of the guidelines suggest features that are already available in existing assistive technology - for example opening an elements list, navigation by headings, or using voice control to jump to an element. Do the guidelines really mean to suggest that the browser should reimplement these as browser features rather than making them features of the AT? It's not clear to me that browsers should be providing these features directly - rather, they should expose rich information to AT via accessibility APIs, and allow AT to innovate ways to present this information to diverse groups of users. | [done] UAWG agrees that there are certainly features which are only applicable to users of assistive technology, and almost anything *could* be delegated (or relegated) to assistive technology. However, there are some features that benefit users who would not require assistive technology. The disadvantages of relying on assistive technology include all of those mentioned above in regard to providing features as extensions, but even more so. Regarding your specific examples, note that 2.5.2 (Provide Navigation by Heading and within Tables) is implemented by extensions for some browsers. Navigation by heading is required but not speech input navigation by heading. | Accept | substantive | ||
| General Comments | AP01: I think most of the UAAG can already be achieved in most browsers with a combination of user style sheets and user scripts. | [done] UAWG agrees that many items in UAAG2 are relatively easy to achieve with user style sheets and user scripts, but the onus for developing the style sheets and scripts should be on user agent developers rather than users. In order to claim compliance, the claimant must demonstrate that solutions, and any required additional components, are available to non-expert users. Enabling the creation of such solutions is not by itself sufficient. | Partial accept | substantive | ||
| General Comments | MS06: Setting realistic Level A, AA, and AAA success criteria Assuming the working group agrees to narrow the scope of UAAG, we then ask that the delineation between the levels to be reexamined. It is our position that a browser meeting level A should be able to: a) interact with web content that meets WCAG 2.0, and b) facilitate programmatic access of the content and its user interface to and from AT, and c) follow the accessibility settings from the OS, and d) provide an user interface that is generally accessible, such as enabling keyboard control on its own features when operating on an environment where keyboard control is available, and e) nothing more Level AA should consist of success criteria that aid users in case of common content failures and predictable solutions are available. Level AAA should consist of success criteria that aid users in case of content failures and where implementable solutions are available. Microsoft appreciates the aspiration of the working group. But it must be understood that the final deliverable must be grounded on reality and that implementations are necessary for UAAG to be considered for recommendation. We encourage the working group to channel its aspiration and creativity elsewhere where developers can consult for future-generation-ideas instead of cluttering UAAG with unclear, untested, or unrealistic success criteria. | [done] UAWG discussed applying the recommended Level setting and decided that the proposal did not meet all the The way "a) interact with web content that meets WCAG 2.0" is phrased suggests that any SC relating to the rendering of content that fails to completely meet WCAG 2.0 should be relegated to lower priority levels. Just as most users expect browsers to make best efforts to render content that has errors in its HTML, users expect browsers to make reasonable effort to render content that does not fully and accurately comply with WCAG. We believe we'd be doing an injustice to say a browser is doing its part if it fails to make those efforts. Aside from this difference, we've reviewed the proposal and generally agree with the importance of the a, b, c, d criteria you laid out as level A. But it seems that almost all of our success criteria would fit into the delineation proposed for level A. We decided on which SC's should be AA and AAA by balancing the benefit to the user versus the difficulty of implementation. The logic behind the levels section is detailed here: http://www.w3.org/TR/IMPLEMENTING-UAAG20/#intro-conf-levels
|
Not accepted | substantive | Not accepted. See new comments - MS06 | |
| General Comments | MS07: Think beyond desktop computers Another fundamental flaw in UAAG is that it is unclear whether it reflects the reality that user agents are commonly available in mobile phones, tablet, wearable, and television form factors where keyboards, if available, are used for text entry instead of navigation, for example. Indeed, WCAG 2.0 did not account for this in 2008 because these form factors were brand new at the time. But UAAG should be better prepared to address mobile accessibility in 2014. We encourage the working group to closely examine non-desktop environments and consider whether there are unique constraints or requirements as a result. | [done] UAWG put non-desktop examples throughout Implementing UAAG and published a separate Note of Mobile Accessibility Examples from Implementing UAAG. UAWG chose to put most of their non-desktop examples in Implementing UAAG (a W3C Note), so it could be kept up to date without undermining the stability of UAAG success criteria. In addition, UAAG contains broad definitions of keyboard and a note under Principle 2 on Modality independence which also includes references to Indie UI. The term "keyboard" is not limited to physical keyboards, or even the on-screen keyboards provided by the platform. In our document the term also includes physical keyboards that can be connected externally, third-party on-screen keyboards that can add modifiers and navigation keys, and software interfaces that can be used by assistive technology software. UAWG updated Conformance and success criteria to improve the clarity that UAAG applies to mobile and many forms of input and navigation. | Partial accept | substantive | Accepted | |
| General Comments | MS09: Subjectivity must be eliminated We found some success criteria to be too subjective to be tested with any reliability. For example, success criterion 2.3.1 (The user can navigate directly to important elements in rendered content.) contains two subjective terms that makes it essentially untestable—directly and important. It is highly debatable as to which navigation methods are considered as "directly" navigable. It is also impossible to objectively determine what an important element is. We also found it dubious that the working group expects a user agent to make such a subjective decision when humans would have a difficult time making such decision. Thus, even if a user agent attempts to determine what is important, it would still be highly debatable as to whether it has done so successfully. We ask the working group to meticulously remove subjectivity from UAAG. |
[done] UAWG has removed all references to "important elements". UAWG has made "directly" more objective by 1) creating a separate glossary definition of "directly" that is linked to "direct commands"; 2) removing duplication between "direct command" and "keyboard command"; 3) adding links to the definition for "directly" in the success criteria. |
Accept | substantive | Accepted | |
| General Comments | JO02: Some sentences are rather long: Consider breaking them up, for improved readability: eg "UAAG 2.0 encourages configuration requirements rather than requirements for default settings. This is because a default user agent setting may be useful for one user but interfere with the needs of another. " |
[done] UAWG editors did another pass for readability of long sentences | Accept | editorial | Accepted | |
| General Comments | EO17: The tables of contents only have 'Guideline N' as the link. Suggest also linking the guideline shortname because for many readers the numbers do not mean anything and they need the shortname to know the guideline. | [done] | Accept | editorial | ||
| General Comments | EO19: Typos: "webpage" instead of "web page". "timeline" vs. "time line"? | [done] | Accept | editorial | ||
| General Comments- Implementing UAAG 2.0 | MS05: Examples in the implementation document do not make distinction of content, browser, assistive technologies, and OS We recognize the value of personalizing the examples, but these examples are not implementation examples. They are use case scenarios with no explanation of what is expected of the browser as oppose to that of the content, the OS, and the AT. It is understandable that average users do not understand the roles and responsibilities of content, browsers, assistive technologies, and OS. But the working group needs to provide more sufficient context for a technical audience. We believe this problem is a reflection of the lack of focus in UAAG. Take, for example, the second example from 1.2.2. (Maria uses a screen reader. When a table lacks marked up header rows, the user agent gives her the option to have the first row treated as the table header row.) It is entirely unclear as to what is expected to be done from the example. It is possible for the reader to interpret that: a) the browser is supposed to alter the content without authorization from the content author to change the structure of the table, or b) the browser is supposed to alter what it passes through to the accessibility API, or c) the AT is supposed to figure out the table header row from the accessibility API and present it to the user as such, or d) the AT is supposed to interrogate the HTML code, determine the header, ignore the information from an accessibility API, and present the header to the user Since there are so many ways to interpret the example and the lack of scope of what a user agent is, it is essentially not implementable in reality. Microsoft asks the working group to reexamine the fundamental nature of what a user agent is and rewrite UAAG from top to bottom with a more precise understanding of user agents and what can be done to make them more accessible. |
[done] UAWG wrote the examples in Implementing UAAG to be illustrative of common uses by people with disabilities. In order to avoid being excessively prescriptive to the browser, we did not make divisions between platform, OS, browser and assistive technologies, knowing that the field is evolving rapidly, and the accessibility feature that is on the browser on one device, may be on the OS on another. See the UAAG Conformance Applicability Note #7: "Relationship with operating system or platform: The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim." The UAAG Conformance Applicability Note #1: "Recognized Content Only: UAAG 2.0 success criteria only apply to web content and its behaviors that can be recognized by user agents." UAWG has clarified the definition of "recognize". UAWG also edited the example in 1.2.2 to make the browser action more specific.
|
Partial accept | substantive | Not accepted. See new comments MS05 | |
| General Comments- Implementing UAAG 2.0 | EO13: The document is called "Implementing UAAG" however it seems to provide very little specific guidance on actually implementing UAAG technically. Instead it provides information on how people with disabilities use the requirements of UAAG. Thus the title seems very misleading -- that the doc will provide something that it does not. It seems it would be better titled "Understanding UAAG". | [done] UAWG agreed to change the name to UAAG 2.0 Reference. UAWG was concerned that the name "Understanding UAAG 2.0" was too close to WCAG's "Understanding WCAG", while providing a different structure than WCAG. | Partial Accept | substantive | ||
| General Comments- Implementing UAAG 2.0 | EO18: Examples of users: In most cases, the disability of the user is specified; however in some it is not, for example, Binh in success criterion 1.3.1 and Maximilian in 1.1.6. Without this, it may not be clear why it is necessary to implement the success criterion for the specified user. Suggestion: include disability for all examples. | [done] do another pass of examples looking for missing disabilities. | Accept | editorial | ||
| Implementing UAAG - Levels of Conformance | EO14: I think it's good that you moved most of the levels info to Implementing. I suggest the following restructuring of the section for flow and to focus on what most readers will be interested in -- that is, what the levels mean (not how you determined them) and how they can be used. (Follow up to sept 2013 comment. | [done] Tks for the detailed suggested wording. | Accept | editorial | ||
Specific Comments on UAAG |
||||||
Abstract |
||||||
| Abstract | EO01: I think the abstract needs editing to be clearer, more direct, and simpler. Suggested edit: "UAAG is introduced in the User Agent Accessibility Guidelines (UAAG) Overview. |
[done] UAWG edited Abstract for clarity, and added the link to an outside page for more introductory material. | Accept | Editorial | ||
| Abstract | EO02: Last sentence of second paragraph is not clear. I don't really understand what it is for. |
[done] Reworded for clarity. It means UAAG doesn't replace the need for assistive technology. | Accept | editorial | ||
| Abstract | EO15: "The "User Agent Accessibility Guidelines 2.0" (UAAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI)." To: "For an introduction to UAAG, see the <a href="http://www.w3.org/WAI/intro/uaag">User Agent Accessibility Guidelines (UAAG) Overview.</a>" or "UAAG is introduced in the <a href="http://www.w3.org/WAI/intro/uaag">User Agent Accessibility Guidelines (UAAG) Overview.</a>" or such -- and include this sentence in the both the Abstract and the Introduction of both UAAG and Implementing UAAG. | [done] | Accept | editorial | ||
| Abstract | EO16: As a general rule, the Abstract of a document should have a short summary of the main point(s) of the document, and as such, any information that is in the Abstract should be in the main document. Both UAAG and Implementing UAAG have info in the Abstract that is not elsewhere. Currently much of the Abstracts seems more like Background and Introduction material, and there is duplication between the two documents. Please consider moving much of the information from both Abstracts into a section of Implementing, and pointing to that from the UAAG intro (based on previous decision to put most of the non-normative info in Implementing so that you can edit it later if warranted). (We hope that the abstract is being rewritten in response to our December 2013 comments and therefore we are not commenting more specifically at this time.) | [done] | Accept | editorial | ||
| Abstract - Implementing UAAG | EO20: Second paragraph ("This document provides explanation of the intent of UAAG 2.0 success criteria, examples of implementation of the guidelines, best practice recommendations and additional resources for the guideline.") is not clear. Why "success criteria" first, then "guidelines" (plural), then "guideline" (singular)? Is this referring to the Guidelines as a document, or the individual success criteria and guidelines, or other? Does this document have anything at the guideline level or is it all at the SC level? If the latter – and based on above suggestion to address issues in the Abstract, maybe Abstract becomes: [[ This document provides supporting information for User Agent Accessibility Guidelines (UAAG) 2.0, a standard for accessible "user agents" (browsers, media players, and applications that retrieve and render Web content). It provides information on the scope of UAAG, conformance with UAAG, relationship of UAAG with other accessibility guidelines, and other general guidance. It explains the intent of each UAAG success criterion, provides examples of how people with disabilities use implementations of the success criterion, and lists related resources. For an introduction to UAAG, see the User Agent Accessibility Guidelines (UAAG) Overview. ]] (Wording also avoids "best practice recommendations" because it can be a problem in the legal area, according to Gregg V.) |
[done] | Accept | editorial | ||
Status |
||||||
| Status | EO03: Suggested revision:
Either remove "the" from the acronym expansion, leaving just "World
Wide Web Consortium", or remove the acronym expansion completely. Rationale: First option is more accurate, second option because the acronym "W3C" is more recognizable than its expansion (and faster to hear). |
[done] Removed "the" where it was not required in code provided by Pubrules. | Partial | Editorial | ||
Introduction |
||||||
| Introduction: Overview | JO01: Some commas needed: "Thus, many UAAG 2.0 requirements use configuration to ensure that a functionality designed to improve accessibility, for one user, does not interfere with accessibility for another." | [done] "Many UAAG 2.0 requirements use configuration preferences to ensure that a feature designed to improve accessibility for one user does not interfere with the needs of another user. " | Accept | editorial | Accepted | |
| Introduction: Overview | JO03: #3: This sentence isn't idea, and a little difficult to parse: Firstly the line: ""For example, a feature required by UAAG 2.0 may be ineffective or cause content to be less accessible, [...]" may not give the best 'first impression' of UAAG! To maintain the gist of the sentence and (shine a favourable light on UAAG, as well as it's supporting documentation etc) how about: "For example, if some feature required by UAAG 2.0 inadvertently caused some content to be less accessible, it would be imperative that the user be able to turn off that feature. Therefore, to avoid overwhelming users with an abundance of configuration options, UAAG 2.0 includes requirements that promote clear documentation and ease of configuration." | [done] Removed some sentences and collapsed the paragraphs. | Accept | editorial | Accepted | |
| Introduction: Overview | EO04: Current wording: ...have control over their environment for accessing the web. Suggested revision: ...have equal control over the environment they use to access the web. Rationale: No one has full "control over their environment," but all should have the same degree of control |
[done] | Accept | editorial | ||
| Introduction: Overview | EO05: Current wording: Although author preferences are important, UAAG 2.0 includes requirements to override certain author preferences when the user would not otherwise be able to access that content. Suggested revision: Omit Rationale: Seems like a non sequitur. Don't understand why that aspect of UAAG is particularly called out, seems a distraction. |
[done] removed. Also see JO04. | Accept | |||
| Introduction: Overview | EO06: Needs editing. For example "Improving accessibility means considering a wide range of disabilities." needs to be stronger. These include visual, auditory, physical, speech, cognitive, language, learning, neurological disabilities, and disabilities related to aging." — consider using updated WAI wording: including auditory, cognitive, neurological, physical, speech, and visual disabilities. |
[done] | Accept | editorial | ||
| Introduction: Overview | EO07: "The UAWG expects that software that satisfies the requirements of UAAG 2.0 will be more flexible, manageable, extensible, and beneficial for a broad range of users." -- Why is this in the normative guidelines? | [done] It is not in the normative guidelines, but in the Overview. It describes the benefits of using UAAG, and seems appropriate for the Introduction. | Accept | Question | ||
| Introduction: Overview | JO04: #4: This is an important clause IMO, and isn't clear - and may also be a red flag for some readers. Remove - 'although author preferences are important' - it's much clearer as: "In some cases, UAAG 2.0 includes requirements to override author preferences when the user would not otherwise be able to access content." A link to an example may help: Or even better - remove the section "the user would not otherwise be able to access content." This may seem a little extreme but as there just isn't clarification, or a URI nearby this sentence may just cause confusion. A way to deal with that would be to just state early on, that "In some cases, UAAG 2.0 includes requirements to override author preferences." - as this is clear statement of fact. That text could be a link to a section with more info on the subject, and/or later on, further down in the document it's expanded on to give the reader a better sense of context. As the wording currently is, it's sounds a little apologetic to me. "Oh, we know that author preferences are important but we are going to overide them anyway!". My preference would be to state first that this is possible, and then in a relevant section - clarify and qualify the statement. | [done] removed sentence. See EO05. | Accept | editorial | Accepted | |
| Introduction: UAAG Layers of Guidance | EH01: #3 Success Criteria - "Each success criterion is assigned a level. The levels are designed to meet the needs of different groups and different situations: A (low, or basic, conformance), AA (recommended conformance), and AAA (@@highest conformance). Additional information on UAAG levels can be found in the Levels of Conformancesection. @@elsewhere it is called "advanced" Elsewhere it is called advanced. |
[done] standardized the terms across the documents to: Level A (minimum), AA (recommended), AAA (advanced) | Accept | editorial | ||
| Introduction: UAAG Layers of Guidance | JO05: #5: Under "UAAG 2.0 Layers of Guidenace" when listing the principle, put a line break before the list starts, and then when it ends. It looks bunched up. Also line breaks after the Princliples section, Guidelines sections etc. | [done] make CSS change | Accept | editorial | Accepted | |
| Introduction: UAAG Layers of Guidance | EO08: Each success criterion is assigned a level. The levels are designed to meet the needs of different groups and different situations: A (low, or basic, conformance), AA (recommended conformance), and AAA (highest conformance).' uses different terminology than the Levels sections, which say: "A (basic), AA (recommended), and AAA (advanced)" | [done] standardized the terms across the documents to: Level A (minimum), AA (recommended), AAA (advanced). See EH01 | Accept | editorial | ||
| Introduction: UAAG Layers of Guidance | EH09: In the paragraph explaining the principles, what about adding a link to Web Content Accessibility Guidelines 2.0. It would allow the reader to go to WCAG if they want to look at WCAG's principles. Related text: Principles 1, 2, and 3 are parallel to Web Content Accessibility Guidelines (WCAG) 2.0. |
[done] Added link to WCAG Overview | Accept | editorial | ||
| Introduction: Components | JO06: #6: Add the word 'both': Under "Components of Web Accessibility" "Web accessibility depends on both accessible user agents and accessible content. " | [done] | Accept | editorial | Accepted | |
| Introduction: Levels of Conformance | JO07: #7: Could you say "The level of accessibility for web content is largely influenced by the authoring tool used to create it."? #7 Under "Levels of Conformance" Remove - "Having too many options may be overwhelming for some users." and rearrange the sentence order as follows: "The levels can help user agent developers decide which options to provide in a basic user interface, and which to provide through progressive disclosure to advanced users. UAAG 2.0 has many options that can be managed through preference settings." | [done] | Accept | editorial | Accepted | |
| Introduction: Levels of Conformance | EO10: This section jumps around. The heading is "Levels of Conformance" but only the first section is about conformance. See levels comments on Implementing below. Maybe this section should stay "Levels of Conformance" and contain only the following. | [done] | Accept | editorial | ||
| Introduction: Definition of User Agent | OP01: On a higher level, the definition of 'User Agent' is too broad. More specifically, 'web based user agents' are essentially websites, and thus should comply by the WCAG guidelines rather than the UAAG. So let us please keep 'web based user agents' which are essentially web apps/webs sites out of the definition of a 'User Agent'. | [done] See MS01 | Not accepted | substantive | ||
| Introduction: Definition of User Agent | MS01: Definition of “User agent” should not include “web-based user agent”
We are strongly opposed to the interpretation that web content such as online translation services, email services, and document authoring services should be included as user agents. These services, when consumed via the web, are web content and should consult WCAG 2.0, not UAAG 2.0 for accessibility guidance. Adding UAAG 2.0 to the mix of applicable guidance to web content already applicable with WCAG 2.0 makes it confusing for content producers to determine which W3C accessibility guideline to follow. It also makes the already muddled UAAG 2.0 even more so by diluting focus from its primary goal of outlining accessibility guidance for web browsers. Microsoft urges the working group to revise the definition of user agent accordingly and to remove all draft language related to the notion that web services can be considered user agents. |
[done] In order to clarify the relationship between UAAG 2.0 and WCAG 2.0 (and ATAG 2.0) UAWG has added 2 new sections to the Guidelines document Introduction:
For the following reasons, UAWG continues to believe that keeping web-based user agents in the scope of UAAG is reasonable and important: Instead of de-scoping web-based user agents, UAWG will continue to identify exemptions from specific success criteria where necessary (e.g. due to technical limitations). |
Partial accept | substantive | ||
| UAAG 2.0 Guidelines | ||||||
| EO11: Question: is there a reason why "normative" is not linked to a definition and "informative" is? Or is it an oversight? | [done] It was a coding error. The definition was linked, but it was not working correctly. | Accept | Question | |||
UAAG 2.0 Conformance Applicability Notes |
||||||
| Recognized Content Only UAAG 2.0 success criteria only apply to web content and its behaviors that can be recognized by user agents. | ||||||
| Optional Settings: Throughout UAAG 2.0, all required behaviors may be provided as optional preference settings unless a success criterion explicitly says otherwise. For example, if a success criteria requires high contrast between foreground text and its background, the user agent may also provide choices with low contrast. A required behavior does not need to be the default option unless the success criteria explicitly says otherwise. | JO08: #8: UAAG 2.0 Conformance Applicability Notes:
Commas needed:
" UAAG 2.0 success criteria only apply to web content, and its
behaviors, that can be recognized by user agents."
#8: Under "UAAG 2.0 Conformance Applicability Notes:"
Could the Optional Setting text be changed to say that there is a
preference (if this is the case, but I can't see why wouldn't be) for
having a required behavior as a default option (where possible. For example:
"Optional Settings: Throughout UAAG 2.0, all required behaviors may be
provided as optional preference settings unless a success criterion
explicitly says otherwise. [...] While it is preferred to have a
required behavior as a default option, it does not need to be, unless
the success criteria explicitly says otherwise." |
[done] Additional commas would not be grammatically correct. The Optional setting text was changed as suggested. |
Partial accept |
editorial |
Accepted | |
EH02: #2 Optional Settings - @@Throughout UAAG 2.0, all required behaviors@@ - could be “All behaviors required by UAAG 2.0”… |
[done] | Accept | editorial | |||
| Optional Settings: | EH03: #2 @@if a success criteria@@ should be "if a success criterion | [done] | Accept | editorial | ||
| RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language (must, may, should) because these are guidelines and not interoperable specifications. These words in UAAG 2.0 don't have the same sense as they do in RFC 2119. | JO09: #9:
This is a little confusing:
"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language
(must, may, should) because these are guidelines and not interoperable
specifications. These words in UAAG 2.0 don't have the same sense as
they do in RFC 2119."
While UAAG says it doesn't use RFC 2119 language, it obviously these
words but with non normative implication. To say they don't have the
same 'sense', could be improved.
How about?
"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language
(must, may, should) as it is not an interoperable specification. Note,
even if these terms appear from time to time they do not have any RFC
2119 implication. " or similar. |
[done] See EH04 |
Accept |
editorial |
Accepted | |
| RFC 2119 language not used | Suggest a link from "RFC 2119" to a glossary item | [done] definition added | Accept | editorial | ||
| RFC 2119 language not used | EH04: #3 @@have the same sense@@ If they (must, may, should) have special meaning, do we need to say what the meaning is? |
[done] changed to "These words in UAAG 2.0 don't have the stricter meaning as they do in RFC 2119." | Accept | editorial | ||
| Simultaneous satisfaction of success criteria: Users can access all behaviors required by UAAG 2.0 at the same time (e.g. when the user resizes the viewport per 1.8.9, content is reflowed per 1.8.6), except where those behaviors are mutually exclusive. | EH05: @@User can access all behaviors@@ Do you mean “Users must be able to access all behaviors”. Presently this is not clear. |
[done] not accepted. "The user can" is the stylist phrase UAAG uses. |
Not Accepted |
editorial |
||
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). | JO10: Under Guideline 1.1, Summary. Move (1.1.1) so it is before the period.
"Summary: The user can choose to render any type of alternative content
available (1.1.1). "
The summary is a little hard to parse. I'm suggesting some
punctuation/edits as follows:
"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). It's recommended that
users also specify alternative content as a cascade (1.1.5). For
example, firstly alt text, otherwise longdesc, otherwise a descriptive
filename etc. It's recommended that the user can configure caption text
and that a 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)." |
[done] Changed to: "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)." |
Accept |
editorial | Accepted | |
| Summary of 1.1 | EO12: 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). Comment: I'm not sure if this means caption text should not be configurable to obscure the video or controls. Suggested wording: It's recommended that the user can configure the caption text but that text or sign language alternative cannot be configured to obscure the video or the controls (1.1.4) |
[done] See JO10 | Accept | editorial | ||
| Summary of 1.1 | EO13: Comment: The summary does not match the success criteria. | [done] See JO10 | Accept | editorial | ||
| A | 1.1.1 Render Alternative Content: The user can choose to render any type of recognized alternative content that is present for a content element. (Level A) Note: It is recommended that the user agent allow the user to choose whether the alternative content replaces or supplements the original content element. |
|||||
| A | 1.1.2 Indicate Unrendered Alternative Content: The user can specify that indicators be displayed along with rendered content when recognized unrendered alternative content is present. (Level A) | |||||
| A | 1.1.3 Replace Non-Text Content: The user can request a placeholder that incorporates recognized text alternative content instead of recognized non-text content, until explicit user request to render the non-text content. (Level A) | SH01: Missing 'an' in the sentence after the comma |
[done] |
Accept |
editorial |
|
| AA | 1.1.4 Provide Configurable Alternative Content Defaults: The user can specify which type(s) of alternative content to render by default for each type of non-text content, including time based media. (Level AA) | |||||
| AA | 1.1.5 Facilitate Clear Display of Alternative Content for Time-based Media: For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the following are all true: (Level AA)
Note: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size to meet this requirement. |
|||||
| AAA | 1.1.6 Allow Resize and Reposition of Time-based Media Alternatives: The user can configure recognized alternative content for time-based media (e.g. captions, sign language video) as follows: (Level AAA)
Note 1: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size or hidden to meet this requirement. Note 2: Implementation may involve displaying alternative content for time-based media in a separate viewport, but this is not required. |
|||||
Guideline 1.2 - Repair missing content |
||||||
| Summary: The user can request useful alternative content when the author fails to provide it. For example, showing metadata in place of missing or empty (1.2.1) alt text. The user can ask the browser to predict missing structural information, such as field labels, table headings or section headings (1.2.2). | JO11: Guideline 1.2 - Repair missing content [Implementing 1.2]
Would 'suitable' be better than 'useful?
Summary: The user can request suitable 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).
|
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)
|
|||||
| AAA | 1.2.2 Repair Missing Structure: The
user can specify whether or not the user agent should attempt to insert
the following types of structural markup on the basis of
author-specified presentation attributes (e.g. position and
appearance): (Level AAA)
|
|||||
Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links |
||||||
| Summary: The user can visually distinguish selected, focused, and enabled items, and recently visited links (1.3.1), with a choice of highlighting options that at least include foreground and background colors, and border color and thickness (1.3.2). | JO12: Guideline 1.3 - Provide highlighting for selection, keyboard focus,
enabled elements, visited links [Implementing 1.3]
'And' should only be used at the end of a list of items in a clause:
Summary: The user can visually distinguish selected, focused, enabled
items, and recently visited links (1.3.1) with a choice of highlighting
options, that at least, include foreground and background colors, border
color and thickness (1.3.2). |
[done] |
Accept |
editorial |
Accepted | |
| A | 1.3.1 Highlighted Items: The user can specify that the following classes be highlighted so that each is uniquely distinguished: (Level A)
|
LG04: In 2.4.3, a search match must
be highlighted. However there doesn't seem to be a requirement to
customize the way those results are displayed. By adding search matches
to 1.3.1, those matches would need to be customizable as per 1.3.2. |
[done] UAWG added "Found search results" |
Accept |
substantive |
|
| AA | 1.3.2 Highlighting Options: When highlighting classes specified by 1.3.1 Highlighted Items, the user can specify highlighting options that include at least: (Level AA) | |||||
| AA | * Foreground colors | |||||
| AA | * Background colors | |||||
| AA | * Borders (color, style, and thickness) | |||||
| AA | * Size when the indicator is an image | |||||
| AA | * Blink rate (where implemented) | |||||
Guideline 1.4 - Provide text configuration |
|
|||||
| Summary: The user can set text scale, color, and font family globally (1.4.1, Level A); set text size, color, and font family for element types (1.4.2, Level AA); set line spacing, character spacing, word spacing, text style, and justification globally (1.4.3, Level AA); set text style, margins, and borders for elements (1.4.5, Level AAA); set line spacing, capitalization, hyphenation, margins, and borders globally (1.4.6, Level AAA); and print configured and reflowed text (1.4.4 Level AA). | JO13: 'And' should only be used at the end of a list of items in a clause: | [done] | Accept | editorial | Accepted | |
| Guideline 1.4 Overall | CR02: Settings that allow the user too much control over the layout and formatting invariably cause some web pages to be unusable. As an example, the minimum font size setting can be great for accessibility. However, it can make many websites with more complicated layouts unusable because the relatives sizes of text vs other elements on the page can now be off by a substantial margin. In contrast, most browsers now support a "zoom" feature that magnifies all elements on the page proportionally. To a web author, this is equivalent to the user modifying the width of the window, a case that already needs to be handled gracefully. I don't feel that we should be telling users that they can't use a website because the web author is making the text too small, or using a font that's inaccessible to them. However, it's also counterproductive to give the user so much control that too many sites become impossible to use, and web developers will have no incentive or ability to fix their sites since there are so many permutations they need to support. For example, I worry that the ability to change line spacing,
character spacing, or justification might create more compatibility
problems than they solve accessibility problems. I don't have any
objection to allowing the user to specify font subsitutions, in
comparison. |
[done] UAWG recognizes that additional user options represent added burden for the developer in all phases, including design, implementation, testing, documentation, and support. We explicitly state that the user agent can comply using both built-in features and extensions. However, this approach is definitely inferior to making the features built-in. For example, it increases difficulty for users to find the features, particularly if there isn't a universally obvious way of referring to them when searching, or if the sheer number of available extensions is overwhelming, if the platform allows developers to charge for the extensions, if the extensions lag behind new versions of the user agent or development stops altogether, if the extensions are not supported to the extent the base user agent is, if various extensions prove incompatible with each other, etc. Of course, some of these problems go away if the the user agent manufacturer builds, distributes, and supports the extensions themselves. That said, 1.4 has been reworked to address an overly granualar approach. |
Partial accept |
substantive |
||
| Note 1: Success criteria 1.4.1, 1.4.3, and 1.4.6 address configuration at a global level, that is, it changes all of the text. Success criteria 1.4.2 and 1.4.5 are at an element type level, such as configuring just the heading text. | ||||||
| Note 2: All of the success criteria under guideline 1.4 allow users to override the text characteristics specified by authors, and override user agent defaults. | ||||||
| Note 3: The success criteria in guideline 1.4 can be met through user stylesheets. For platforms without user stylesheets, text configuration needs to be provide to users through the user agent's main user interface. | ||||||
| A | 1.4.1 Text Scale, Color, Font (Globally): The user can globally set all of the following characteristics of visually rendered text content: (Level A) | MS03: Separation between browsers and OS While it is understood that the separation between browsers features and OS features can be blurry at times, there are functions that are generally expected to be provided by the OS to facilitate accessibility. We do not expect the working group to delineate the responsibility of OS and browsers since it is contextual and fluid. But we expect the working group to recognize such separation of responsibility. For example, success criterion 1.4.1 (Text Scale, Color, Font) should be separated into two criteria—one simply asking the browsers to follow the OS text size and such at level A and another to provide its own options if the OS fails to provide text options at level AA. |
[done] UAWG
added a general applicability note #7 to clarify that if the feature is
handled by the OS, the user agent doesn't need to repeat it. |
Partial accept |
substantive |
Not accepted. See new comments - MS03 |
| A | * Text scale with preserved size distinctions (e.g. keeping headings proportional to main font) | |||||
| A | * Text color and background color, choosing from all platform color options | |||||
| A | * Font family, choosing from all platform fonts | |||||
| 1.4.2 Text Size, Color and Font (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings and input fields:(Level AA) | SH02: 1.4.2 and 1.4.3 need a space between the : and ( | [done] | Accept | editorial | ||
| AA | 1.4.2 Text Size, Color and Font (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings and input fields:(Level AA) | WD01:
1.4.2: Problem: Users also need to style hyper links at the
element. Solution: Add: "...at least heading input fields and links."
|
[done] UAWG agreed to change SC as recommended |
Accept |
Substantive |
|
| AA | * Text size | |||||
| AA | * Text color and background color, choosing from all platform color options | |||||
| AA | * Font family, choosing from all platform fonts | |||||
| AA | 1.4.3 Text Spacing and Style (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text:(Level AA) | WD02:
1.4.3: Problem: the lengths for character spacing and word
spacing appear to be absolutes. This would be wrong. Solution: Add a
note. (so you will have Note 1 (as is) and a new Note 2) "
Note 2: The lengths for character and word spacing are
interpreted the same as letter and word spacing CSS 2 and up. The
length value is added to the default character and word spacing for the
font. |
[done] UAWG added clarified the Intent section for 1.4.3 and removed the absolute numbers for 1.4 |
Partial Accept |
substantive |
|
| 1.4.3 Text Spacing and Style (Globally): | SB06: 1.4.3 and 1.4.6 BOTH mention "line spacing" - does it really need to be listed twice? With different settings ranges? or maybe I've misunderstood (which means others might misunderstand). | [done] UAWG simplified guideline 1.4 removing the specific setting ranges, and reducing the mention of line spacing to globally and by element. | Accept | substantive | Accepted | |
| AA | * Line spacing of at least 1.0, 1.3, 1.5, and 2.0 times the font height | |||||
| AA | * Character spacing of at least 0.01, 0.03, 0.06, 0.09 times the base character width | |||||
| AA | * Word spacing of at least 0.01, 0.03, 0.06, 0.09 times the base character width | |||||
| AA | * Text style (underline, italic, bold) | |||||
| AA | * Justification (left, right, or full) | |||||
| Note: For the purposes of UAAG 2.0, the base character width is the font width of the character commonly accepted as the base character for calculating kerning in the typography for that language (e.g. zero character in English). | ||||||
| AA | 1.4.4 Configured and Reflowed Text Printing: The user can print any rendered visual, non-time-based content to the user's choice of available printing devices. (Level AA) | |||||
| Note: The user must be able to print content as it is rendered on screen, reflecting user scaling, highlighting, and other modifications, but reflowable content is reflowed for the print margins. | ||||||
| AAA | 1.4.5 Text Style, Margins, Borders (by Element): The user can set all of the following characteristics of visually rendered text content for main text and for text element types including at least headings and input fields: (Level AAA) | |||||
| AAA | * Text style (underline, italic, bold) | |||||
| AAA | * Margins (for example, space above headings, indentation of lists) | |||||
| AAA | * Borders | |||||
| AAA | 1.4.6 Spacing, Capitalization and Hyphenation (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AAA) | |||||
| AAA | * Line spacing between 0.7 and 3.0 times the font height, at increments of 0.10 | |||||
| AAA | * Capitalization (overriding upper case and small caps style) | |||||
| AAA | * Word-breaking properties (auto-hyphenation) | |||||
| AAA | * Margins | |||||
| AAA | * Borders | |||||
| Note: This success criteria does not apply to text entered as all caps. Content authors are encouraged to use styles instead of typing text as all caps. | ||||||
| Guideline 1.5 - Provide volume configuration | ||||||
| Summary: The user can adjust the volume of each audio track relative to the global volume level (1.5.1). | ||||||
| A | 1.5.1 Global Volume: The user can adjust the volume of each audio tracks independently of other tracks, relative to the global volume level set through operating environment mechanisms. (Level A) | |||||
| Guideline 1.6 - Provide synthesized speech configuration | ||||||
| Summary: If synthesized speech is produced, the user can specify speech rate, volume, and voice (1.6.1, Level A), pitch and pitch range (1.6.2, Level AA), advanced synthesizer speech characteristics such as emphasis (1.6.3, Level AAA) and features such as spelling (1.6.4, Level AAA). | MS02: Separation of assistive technologies from user agents While UAAG 2.0 no longer explicitly includes the AT into its definition of user agent, it is still obvious that AT is targeted as an applicable entity for UAAG implementation. Guideline 1.6, for example, is clearly written for AT instead of browsers. It defies common sense to create one accessibility guideline for AT and browsers. This greatly distracts the primary focus of UAAG, making it less relevant and less suitable for consideration by AT and browser makers. The working group should make it clear that UAAG is not intended for AT regardless of whether AT performs functions that are typically provided by browsers and that UAAG needs to be revised accordingly. |
[done] Providing guidelines for software that does synthesized speech does not equate with targeting AT, which as you've noted is already explicitly exempted. For example, early versions of the Kindle provided text to speech that was not targeting people with disabilities; if browsers provide speech output for mainstream users, they should be making the speech configurable enough to be usable by a wide range of individuals. When an extension adds speech output to the UA, it becomes part of the UA, and, should meet the requirements of 1.6. UAWG clarified 1.6.3 to apply only to UAs that provide synthesized speech. UAWG modified 1.6.3 to clarify that 1.6 only applies to browsers that produce synthesized speech. |
Partial accept |
substantive |
See new comment MS02 "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." |
|
| A | 1.6.1 Speech Rate, Volume, and Voice: If synthesized speech is produced, the user can specify the following: (Level A)
|
|
||||
| AA | 1.6.2 Speech Pitch and Range: If synthesized speech is produced, the user can specify the following if offered by the speech synthesizer: (Level AA) | |||||
| AA | * Pitch (average frequency of the speaking voice) | |||||
| AA | * Pitch range (variation in average frequency) | |||||
| Note: Because the technical implementations of text to speech engines vary (e.g. formant-based synthesis, concatenative synthesis), a specific engine may not support varying pitch or pitch range. A user agent should expose the availability of pitch and pitch range control if the currently selected or installed text to speech engine offers this capability. | ||||||
| AAA | 1.6.3 Advanced Speech Characteristics: The user can adjust all of the speech characteristics provided by the speech synthesizer. (Level AAA) | |||||
| AA | 1.6.4 Synthesized Speech Features: If synthesized speech is produced, the following features are provided: (Level AA) | |||||
| AA | * User-defined extensions to the synthesized speech dictionary. | |||||
| AA | * "Spell-out": text is spelled one character at a time, or according to language-dependent pronunciation rules. | |||||
| AA | * At least two ways of speaking numerals: spoken as individual digits and punctuation (e.g. "one two zero three point five" for 1203.5 or "one comma two zero three point five" for 1,203.5), and spoken as full numbers are spoken (e.g. "one thousand, two hundred and three point five" for 1203.5). | |||||
| AA | * At least two ways of speaking punctuation: spoken literally, and with punctuation understood from speech characteristics like pauses. | |||||
| AA | 1.6.5 Synthesized Speech Language: If synthesized speech is produced and more than one language is available, the user can change the language. (Level AA) | |||||
| Guideline 1.7 - Enable configuration of user stylesheets | ||||||
| Summary: The user agent supports user stylesheets (1.7.1, Level A), the user can choose which if any user-supplied (1.7.2, Level A) and author-supplied (1.7.3, Level A) stylesheets to use, and the user can save stylesheets (1.7.4, Level AA). | MS08: Realistic expectation of the end users We found some of the success criteria related to the use of alternate style sheet to be counterproductive. First, custom-created style sheets are far too complex of a solution for the vast majority of the users. It will more likely result in unintended errors than otherwise. Second, it is not a scalable solution. It is unrealistic to expect users to create a portfolio of style sheets for all the websites and to maintain them as the sites change over time. We believe this is an outdated approach that is no longer relevant in today's web environment and urge the working group to reconsider. |
[done] UAWG agrees with the commenter that relying on user style sheets is a problematic approach to the problem of inadequately designed web content. Unfortunately, at this point we are not aware of any better solutions being proposed. Even if customized user stylesheets are not available to many users, they provide a fall-back solution that would be available to some users, and potentially to more users in the future if efforts are made to share accessible alternative style sheets (e.g. userstyles.org). One solution that the group considered was to require the user agent to provide robust custom styling interface to meet the users requirements in order to give users rich customization options to meet their needs. We thought that improving the usability of user stylesheets was a more realistic alternative at this time. | Not accepted |
substantive |
Not accepted. See new comments - MS08 |
|
| A | 1.7.1 Support User Stylesheets: If the user agent supports a mechanism for author stylesheets, the user agent also provides a mechanism for user stylesheets. (Level A) | |||||
| A | 1.7.2 Apply User Stylesheets: If user stylesheets are supported, then the user can enable or disable user stylesheets for: (Level A) | |||||
| A | * All pages on specified websites, or | |||||
| A | * All pages | |||||
| A | 1.7.3 Disable Author Stylesheets: If the user agent supports a mechanism for author stylesheets, the user can disable the use of author stylesheets on the current page. (Level A) | |||||
| AA | 1.7.4 Save Copies of Stylesheets: The user can save copies of the stylesheets referenced by the current page. This allows the user to edit and load the copies as user stylesheets. (Level AA) | SB01: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed. |
[done] SB01: UAAG 2.0 Reference
explains the rationale for this. Let us know if after reading that
explanation you still feel it is not needed. It should be noted that
many browsers already implement this success criteria. |
Not accepted |
substantive | Not accepted. See new comments - SB01 |
| 1.7.4 Save Copies of Stylesheets: | LG02: To save some crucial load time and bandwidth for mobile users, it is custom
to compress stylesheets and scripts (the process is usually called
minification). Considering this, it would be highly beneficial if the saved
stylesheet were saved in a pretty-print manner to facilitate authoring by
users.
Note that minification is not as important for local stylesheet as files loaded locally don't incur the overheads of HTTP requests. |
[done] UAWG agreed with this point as a best practice and added it to UAAG 2.0 Reference. | Accept | substantive | ||
| Guideline 1.8 - Help users to orient within, and control, windows and viewports | ||||||
| Summary: The user agent provides programmatic and visual cues to keep the user oriented. These include highlighting the viewport (1.8.1, Level A) and customizing the highlighting attributes (1.8.8, Level AA), keeping the focus within the viewport (1.8.2 & 1.8.6, Level A), resizing the viewport (1.8.9, Level A), providing scrollbars that identify when content is outside the visible region (1.8.3, Level A) and which portion is visible (1.8.4, Level A), changing the size of graphical content with zoom (1.8.5, Level A & 1.8.7, Level A), and restoring the focus and point of regard when the user returns to a previously viewed page (1.8.10, Level AA). The user can specify that all viewports have the same user interface elements (1.8.13, Level AA), if and how new viewports open (1.8.11, Level AA), and whether the new viewport automatically gets focus (1.8.12, Level AA). The user can mark items in a webpage and use shortcuts to navigate back to marked items. (1.8.14, Level AAA). | JO14:
'And' should only be used at the end of a list of items in a
clause. I'm wondering out loud if these summaries may be better as a
list of
items? This one is large and easy to get lost in IMO. |
[done] UAAG agreed that summary was a large one, but didn't want to change the style just for one or two summaries. |
Partial accept |
editorial |
Accepted | |
| 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) | EO21: Example 2 is not clear. Why and how George should scroll? ("George uses a screen reader. He is showing a sighted colleague how to complete a registration form that's contained within a viewport. The form exceeds the vertical bounds of the viewport, requiring George to scroll vertically to view the complete form content. When George completes each form entry, if the next form is not already visible in the viewport, it scrolls into view.") |
[done] UAWG agreed to make it clear why the user was scrolling. |
Accept |
editorial |
|
| A | 1.8.3 Provide Viewport Scrollbars: When the rendered content extends beyond the viewport dimensions, users can have graphical viewports include scrollbars, overriding any values specified by the author. (Level A) | |||||
| A | 1.8.4 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level A) | |||||
| A | 1.8.5 Allow Zoom: The user can rescale content within top-level graphical viewports as follows: (Level A) | |||||
| A | * Zoom in: to 500% or more of the default size | |||||
| A | * Zoom out: to 10% or less of the default size, so the content fits within the height or width of the viewport | |||||
| A | 1.8.6 Maintain Point of Regard: The point of regard remains visible and at the same location within the viewport when the viewport is resized, when content is zoomed or scaled, or when content formatting is changed. (Level A) | |||||
| A | 1.8.7 Reflow Text: The user can specify that text content in a graphical top-level viewport reflows so the text forms a single column that fits within the width of the viewport. (Level A) Note 1: Reflow applies even when text is rescaled or zoomed. Note 2: For vertical layout languages (e.g. Mongolian, Han), text should fit within the height of the viewport, rather than its width, to reduce vertical scrolling |
SB02: 1.8.7 (Reflow Text) - I think there's a possible
misunderstanding here with the wording "text content in a
graphical top-level viewport". Some developer might think "oh,
if it's only about text in a top-level viewport, then it doesn't
apply to text in a table (or other layout device) within that
viewport", which is not ideal especially if such layout device
is being used unnecessarily. Maybe add something like "This
applies even if such text is included within other structures"? |
[done] Multi-faceted response: Moved Note 2 to general Applicability Notes (2014-02-06 meeting). We decided we needed to say more on this topic and added proposals for additional SC approved in the meeting of 2014-02-20. Removing 1.8.7. |
Partial accept |
substantive |
Accepted |
| AA | 1.8.8 Customize Viewport Highlighting: When highlighting viewports as specified by 1.8.1 Highlight Viewport, the user can customize attributes of the viewport highlighting mechanism (e.g. blink rate for blinking, color and width of borders). (Level AA) | |||||
| AA | 1.8.9 Allow Viewport Resize: The user can resize viewports within restrictions imposed by the platform, overriding any values specified by the author. (Level AA) | |||||
| AA | 1.8.10 Provide Viewport History: For user that implement a history mechanism for top-level viewports (e.g. "back" button), the user can return to any state in the viewport history that is allowed by the content, including a restored point of regard, input focus and selection. (Level AA) | |||||
| AA | 1.8.11 Allow Top-Level Viewport Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA) | SB03: Re 1.8.11 (Allow Top-Level Viewport Open on Request) it might also be worth explicitly stating that, if the user performs some action whose normal meaning is "open link in new tab" (for example, middle-click on some browsers) then it should be possible for users to specify that such actions must ALWAYS perform that meaning, and cannot be overridden by the page author. Some Javascript "onClick" events manage to (accidentally) override middle-clicks and cause something to happen on the current page instead of opening a new tab. (In many cases this can be worked around by right-clicking on the link and selecting "open in new tab", instead of middle-clicking, but that can be extra effort and it's an annoyance.) | [done] UAWG:
We agree with the sentiment but unfortunately as you say those
non-standard behaviors are usually implemented in Javascript, so the
user agent may not be able to interfere in any reliable way other than
by blocking scripts altogether. (It could fail a script's calls to the
function that opens a new top-level viewport, but it can't force the
script to make such a call.) |
Not accepted |
substantive |
Not accepted. See new comments - SB03 |
| AA | 1.8.12 Allow Top-Level Viewport Focus Control: If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open. (Level AA) | |||||
| AA | 1.8.13 Allow Same User Interface: The user can specify that all top-level viewports (e.g. windows or tabs) follow the defined user interface configuration. (Level AA) | |||||
| AAA | 1.8.14 Provide Webpage Bookmarks: The user can mark items in a webpage, then use shortcuts to navigate back to marked items. The user can specify whether a navigation mark disappears after a session, or is persistent across sessions. (Level AAA) | SH03: 1.8.14 is a good idea but I think we need to make it clear that persistence is not guaranteed if the page elements have changed and there needs to be some way to notify people that the marked content has changed or been lost. Also typo space required between . And ( |
[done] UAWG added a new conformance note that includes no guaranty of persistence. UAWG also added a new conformance applicability note stating the UAAG only applies to retrieved content. |
Accept |
substantive | |
| Guideline 1.9 - Provide alternative views | ||||||
| Summary: The user can view the source of content (1.9.2, Level AAA), and an outline view of important elements. (1.9.1, Level AA). | ||||||
| AA | 1.9.1 Outline View: Users can view a navigable outline of rendered content composed of labels for important elements, and can move focus efficiently to these elements in the main viewport. (Level AA) | |||||
| Note: The important elements depend on the web content technology, but may include headings, table captions, and content sections. | ||||||
| AAA | 1.9.2 Source View: The user can view all source text that is available to the user agent. (Level AAA) | |||||
| Guideline 1.10 - Provide element information | ||||||
| Summary: The user can access information about relationships between elements (e.g. form labels, table headers) (1.10.1, Level AA), and extended link information (e.g. title, internal vs. external) (1.10.2, Level AAA)Thanks | OP04: "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)"
I think there are browser extensions which do a similar job, and if not, can be made to do a similar job. In general, a lot of the guidelines in the UAAG would be better solved if we let browser extensions do the job rather than ask user agents themselves to do it. I would very strongly suggest the guidelines allow the user agents do the things mentioned in the guidelines themselves, or *alternatively provide an API for extensions to be able to do it*. |
[done] UAWG added a more prominent Applicability Note clarifying that extensions can be used. |
Accept |
substantive |
||
| AA | 1.10.1 Show Related Elements: The user can access related elements based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA) | SH04: For 1.10.1 are we assuming that close elements will be close in the DOM. I'd think this would be hard based on the visual rendering, and would require some idea of the semantics of the association. I'd also think that a label to a form element could be close in DOM for distant in the visual rendering based on the CSS, how is this handled? |
[done] UAWG changed 1.10.1 to list specific elements where the user agent presents labels, independent of the location in the DOM. The requirement for proximity was removed. |
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: Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. If every potential user task is made accessible via modality independent controls that any input technology can access, a user can use what works best. For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. See Independent User Interface: Events for additional information on APIs and techniques for modality independent controls. | JO15: Need a little rewrite/punctuation - see below:
Note: This sentence is confusing:
If every potential user task is made accessible via modality independent
controls that any input technology can access, a user can use what works
best.
How about?
"If every potential user task is made accessible, so multiple modalities
are supported, that a user can choose what works best."
NOTE: I think I have a larger issue around the term "modality
independent controls"! I know what it is saying, but I'm not sure I like it. |
Accepted | ||||
| Guideline 2.1 - Ensure full keyboard access | ||||||
| Summary: Every viewport has a keyboard focus (2.1.2, Level A). Users can operate all functions using just the keyboard (2.1.1, Level A), activate important or common features with shortcut keys, (2.1.6, Level A), escape keyboard traps (2.1.3, Level A), specify that selecting an item in a dropdown list or menu not activate that item (2.1.4, Level A) and use standard keys for its platform (2.1.5, Level A). | ||||||
| A | 2.1.1 Provide Full Keyboard Functionality: All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A) | |||||
| A | 2.1.2 Show Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times. (Level A) | |||||
| A | 2.1.3 Avoid Keyboard Traps: If keyboard focus can be moved to a component using a keyboard interface (including nested user agents), then focus can be moved away from that component using only a keyboard interface. If this requires more than unmodified arrow or Tab keys (or standard exit methods like Escape), users are advised of the method for moving focus away. (Level A) | |||||
| A | 2.1.4 Separate Selection from Activation: The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author-supplied content. (Level A) | |||||
| A | 2.1.5 Follow Text Keyboard Conventions: The user agent follows keyboard conventions for the operating environment. (Level A) | |||||
| A | 2.1.6 Make Keyboard Access Efficient: The user agent user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level A) | |||||
| Guideline 2.2 - Provide sequential navigation | ||||||
| Summary: Users can use the keyboard to navigate sequentially to all the operable elements in the viewport (2.2.1, Level A) as well as between viewports (2.2.2, Level A), and the default navigation order is document order (2.2.3, Level A). Users can optionally disable wrapping or request a signal when wrapping occurs (2.2.4, Level AA). | JO16: Small edit:
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). |
[done] |
Accept |
editorial |
Accepted | |
| Guideline 2.2 - all SC | OP02: "Users can use the keyboard to navigate sequentially to all the operable elements in the viewport (2.2.1, Level A) as well as between viewports (2.2.2, Level A), and the default navigation order is document order (2.2.3, Level A). Users can optionally disable wrapping or request a signal when wrapping occurs (2.2.4, Level AA)." The above might make sense in desktop browsers, but on other kind of browsers like mobile browser on certain platforms, TV browsers, it might not make sense. | [done] UAWG added an example sentence to the Principle 2 note on Device Independence. | Accept | substantive | ||
| 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) | MS04 applies here |
[done] UAWG added "rendered content of the current viewport" to make it more specific. |
Accept |
substantive | |
| A | 2.2.2 Sequential Navigation Between Viewports: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A) | |||||
| A | 2.2.3 Default Navigation Order: If the author has not specified a navigation order, the default sequential navigation order is the document order. (Level A) | |||||
| AA | 2.2.4 Options for Wrapping in Navigation: The user can request notification when sequential navigation wraps at the beginning or end of a document, and can prevent such wrapping. (Level AA) | |||||
| Guideline 2.3 - Provide direct navigation and activation | ||||||
| Summary: Users can navigate directly (e.g. using keyboard shortcuts) to important elements (2.3.1, Level AA) with the option of immediate activation of the operable elements (2.3.3, Level A). Display commands with the elements to make it easier for users to discover the commands (2.3.2 & 2.3.4, Level AA). The user can remap and save direct commands (2.3.5, Level AA). | JO17: Small edit:
Summary: Users can navigate directly (e.g. using keyboard shortcuts) to
important elements (2.3.1, Level AA) with the option [to immediately
activate] operable elements (2.3.3, Level A). Display commands with the
elements to make it easier for users to discover the commands (2.3.2 &
2.3.4, Level AA). The user can remap and save direct commands (2.3.5,
Level AA). |
[done] |
Accept |
editorial | Accepted | |
| Summary: | OP06:"Users can navigate directly (e.g. using keyboard shortcuts) to
important elements (2.3.1, Level AA) with the option of immediate
activation of the operable elements (2.3.3, Level A). Display commands
with the elements to make it easier for users to discover the commands
(2.3.2 & 2.3.4, Level AA). The user can remap and save direct commands
(2.3.5, Level AA)." and also the following:
"Elements determined as important by the user to facilitate the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary by user needs and technologies being used." Since important elements have been left at the discretion of the user (and will vary from user to user, and from web page to web page) ... It will be quite the task for the user agent to determine from the user which elements he/she thinks is important and have the proper facilities to navigate directly to it. Can make the criteria of 'important elements' more objective or easily definable? |
[done] UAWG has removed all references to "important elements" | Accept | substantive | ||
| AA | 2.3.1 Allow Direct Navigation to Important Elements: The user can navigate directly to important elements in rendered content. (Level AA) | |||||
| AA | 2.3.2 Present Direct Commands from Rendered Content: The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email). (Level AA) | OP07:[On the Intent of 2.3.2] "For many users, including those who use the keyboard or an input
method such as speech, the keyboard is often a primary method of user
agent control. It is important that direct keyboard commands assigned
to user agent functionality be discoverable, including in rendered
content. If direct commands are not presented in content, many users
will not discover them."
However, if we are to have proper documentation of the accessibility functionality (Guideline 3.3) then, presumably, there it will be made discoverable. Users will just need to go through the documentation to discover all relevant controls. |
[done] UAWG
responds that this is a misunderstanding. The documentation of the
accessibility functionality is for the user interface, but this
discoverability SC is for rendered content. The user agent can not have
documentation for author-supplied direct commands (accesskey). |
Not Accepted |
substantive |
|
| A | 2.3.3 Allow Direct Activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A) | |||||
| AA | 2.3.4 Present Direct Commands in User Interface: The user can have any direct commands in the user agent user interface (e.g. keyboard shortcuts) be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) | MS04: Delineate between content and browser There should be clear separation of the guidelines that are applicable to the browser itself (such as 3.2.2 or 2.3.4) and how it handles web content (such as 3.2.3 and 2.2.1). In theory, success criteria applicable to handling of web content should always contain the term "rendered content" to make this distinction clear. But this is, unfortunately, not done with any consistency. For example, guideline 2.2 are clearly applicable to browser treatment of rendered content, but the term never appears in its four success criteria. This makes it difficult for the audience to interpret the intention of the guidelines. |
[done] UAWG edited the definition of rendered content to make it more specific and linked to the definition wherever "rendered content" was used. UAWG reviewed the use of the terms in context and made adjustments where necessary. UAWG added a new section, Applies To, to UAAG 2.0 Reference for each success criterion that itemizes what aspects of the user agent apply to each. |
Accept |
substantive |
Approve |
| 2.3.4 Present Direct Commands in User Interface: | EO22: In first example, there are some strange sign that I cannot identify, may be it makes sense graphically, but not in braille, and nothing is pronounced by the speech synthesizer. Here is what I can read: "notices that the menu item has a "⌘" label (e.g. "Copy ⌘+C")." Can you change the example to not use the sign? If not, please make it clear to screen reader users. | [done] The editor changed the coding to enclose the character in an abbreviation tag with the title of "command key". | Accept | editorial | ||
| AA | 2.3.5 Allow Customized Keyboard Commands: The user can remap any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level AA) | |||||
| Guideline 2.4 - Provide text search | ||||||
| Summary: Users can search rendered content (2.4.1, Level A) forward or backward (2.4.2, Level A) and can have the matched content highlighted in the viewport (2.4.3, Level A). The user is notified if there is no match (2.4.4, Level A). Users can also search by case and for text within alternative content (2.4.5, Level AA). | JO18: Small edit/punctuation
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
way] 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). |
[done] |
Accept |
editorial |
Accepted | |
| 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) | EO23: The 4th example on Sam is not clear. I am not sure that many blind users disable images in their browsers as images do not need to be disabled to hear their alt attribute spoken by screen readers. Please think about how realistic this example is. ("Sam is a screen reader user. He has images off and the alternative content for images is revealed. He wants to send the flow chart image on the page to a collegue. Sam searches for the word "flowchart" that he heard spoken as part of the 'alt' text for the image. He then uses the context menu to select the address of the image and sends it to a colleague. ") (Also typo: "collegue" -> "colleague".)
|
[done] The sentence about disabling images was removed. | Accept |
editorial |
|
| 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) | LG04: In 2.4.3, a search match must be highlighted. However there doesn't seem to
be a requirement to customize the way those results are displayed. By
adding search matches to 1.3.1, those matches would need to be customizable
as per 1.3.2. |
[done] UAWG added "found search results" to 1.3.1 which covers highlighting and customization. |
Accept |
substantive |
|
| 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) | LG03: 2.11.2 and 2.11.3 requires the ability to block execution or playback of
media. However in 2.4.5, searching a page should also search in captions,
which may not be loaded as per 2.11.2 / 2.11.3. The examples for 2.4.5
mention that the user agent moves to the specified point in the video.
Am i misunderstanding? |
[done] UAWG added a new applicability note to clarify that search and other UAAG success criteria only apply to content that is loaded. It was unrealistic and potentially detrimental to require ALL content before searching (maps, infinite scrolls, etc) even though it would be useful to be able to search material that was not typically loaded, there were other ways that users can get the material to load before conducting the search. |
Accept |
substantive |
|
| Guideline 2.5 - Provide structural navigation | ||||||
| Summary: Users can view (2.5.1, Level AA), navigate (2.5.2, Level A), and configure the elements used in navigating (2.5.3, Level AAA) content hierarchy. | ||||||
| AA | 2.5.1 Show Location in Hierarchy: When the user agent is presenting hierarchical information, but the hierarchy is not reflected in a standardized fashion in the DOM or platform accessibility services, the user can view the path of nodes leading from the root of the hierarchy to a specified element. (Level AA) | |||||
| AA | 2.5.2 Provide Navigation by Heading and within Tables: The user agent provides at least the following types of structural navigation, where the structure types exist: (Level AA) * By heading |
EO24: I don't understand the meaning of 4th example that talks about blindness, speech command and heading navigation. Please explanation this more clearly. ("Armand is blind. When he uses the speech input to locate a web page on his smartphone, Armand navigates from heading to heading using touch commands.") |
[done] The sentence was changed to explicitly refer to the iOS Rotor as an example. |
Accept |
editorial |
|
| AA | 2.5.2 Provide Navigation by Heading and within Tables: | EO25: Copyedit: In third example on Celia, it would be useful to add a comma after "document": "When looking for any particular section of the document she finds it easier to scan through headings".
|
[done] |
Accept |
editorial |
|
| AAA | 2.5.3 Allow Elements to be Configured for Structural Navigation: The user can configure a set of important elements (including element type) for structured navigation and hierarchical/outline view. (Level AAA) | |||||
| Guideline 2.6 - Provide access to event handlers | ||||||
| Summary: Users can interact with web content by mouse, keyboard, voice input, gesture, or a combination of input methods. Users can discover what event handlers (e.g. onmouseover) are available at each element and activate an element's events individually (2.6.1). | ||||||
| AA | 2.6.1 Allow Access and Activation of Input Methods: The user agent provides a means for the user to determine recognized input methods explicitly associated with an element, and a means for the user to activate those methods in a modality independent manner. (Level AA) | SB04: Re 2.6 - I think there definitely needs to be some easily-accessible switch to temporarily STOP all event handlers, then start them again later. Some websites have badly-implemented scripts that try to do fancy things as you move the mouse over elements, and these play badly with user stylesheets. For example, eBay's feedback mechanism can go horribly wrong at very large zoom levels. You move the mouse over the "5 star" rating, but as you do so, it adds an extra element into the text, causing the whole thing to reflow (the designers weren't expecting it to reflow - they didn't think it might be zoomed), and the reflow takes the star somewhere else so it is no longer under the mouse pointer, and this causes another event, undoing the first event, but then the star is again under the pointer, and so on ... result is a rapidly-flickering control, and less than 50/50 chance of it being activated when you click. Only workaround is to zoom out or increase the window size, but I wish I had a button that says "stop all event handlers until my next click" (bonus points if the user agent can AUTOMATICALLY detect the "rapid-fire" situation and turn them off until the next click). | [done] UAAG:
SC 2.11.3 already requires the user be able to turn off scripts, but it
does not require that it be easy or convenient (nor that it be specific
to a the current top-level viewport). That could potentially be added
as a separate, lower-level SC, but I'm not sure how we'd say what is
required to be convenient. By the way, your example is a good one that we added to UAAG 2.0 Reference. |
Partial accepted |
substantive |
Not accepted. See new comments - SB04 |
| 2.6.1 Allow Access and Activation of Input Methods | CR06: Guideline 2.6 suggests that "users can discover what event handlers (e.g. onmouseover) are available at each element". This is impossible to implement - it's quite commonplace for a web author to install a global event listener, or an event listener on a container element, and decide what to do depending on the target element of each event that bubbles up. | [done] UAAG: In this case the success criteria is actually limited to "recognized input methods explicitly associated with an element", so the user agent is not expected to present the user with a list that includes every possible event being handled by a global event listener, if the specific technology does not allow it to tell which specific events are being watched for. However, if the user agent can tell, for a given element, which events are being listened for by a element-specific, container element, or global listeners, it should be able to make this list available to the user. | Partial accept | substantive | ||
| 2.6.1 Allow Access and Activation of Input Methods | AP02: In the specific case of this one: 2.6.1 Allow Access and Activation of Input Methods: I'm hopeful this one will be solved by IndieUI Events. | [done] UAWG added a link to the Indie UI WG from the Related Resources section of 2.6.1 | Accept | substantive | ||
| Guideline 2.7 - Configure and store preference settings | ||||||
| Summary: Users can restore preference settings to default (2.7.2, Level A), and accessibility settings persist between sessions (2.7.1, Level A). Users can manage multiple sets of preference settings (2.7.3, Level AA), and adjust preference setting outside the user interface so the current user interface does not prevent access (2.7.4, Level AA), and transport settings to compatible systems (2.7.5, Level AA). | JO19: Summary: Users can restore preference settings to default (2.7.2, Level
A), and accessibility settings persist between sessions (2.7.1, Level
A). Users can manage multiple sets of preference settings (2.7.3, Level
AA), and adjust preference setting[s] 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).
|
[done] |
Accept |
editorial |
Accepted | |
| A | 2.7.1 Allow Persistent Accessibility Settings: User agent accessibility preference settings persist between sessions. (Level A) | |||||
| A | 2.7.2 Allow Restore All to Default: The user can restore all preference settings to default values. (Level A) | |||||
| AA | 2.7.3 Allow Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA) | |||||
| AAA | 2.7.4 Allow Preference Changes from outside the User Interface: The user can adjust any preference settings required to meet the User Agent Accessibility Guidelines (UAAG) 2.0 from outside the user agent user interface. (Level AAA) | |||||
| AAA | 2.7.5 Make Preference Settings Transferable: The user can transfer all compatible user agent preference settings between devices. (Level AAA) | |||||
| Guideline 2.8 - Customize display of graphical controls | ||||||
| Summary: It's recommended that users can add, remove, reposition, and assign shortcuts to user agent controls, and restore them to their default settings (2.8.1, Level AA). | ||||||
| AA | 2.8.1 Customize Display of Controls for User Interface Commands, Functions, and Extensions: The user can customize which user agent commands, functions, and extensions are displayed within the user agent user interface as follows: (Level AA) | |||||
| AA | * Show: The user can choose to display any controls available within the user agent user interface, including user-installed extensions. It is acceptable to limit the total number of controls that are displayed onscreen. | |||||
| AA | * Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some controls). | |||||
| AA | * Reposition: The user can choose to reposition individual controls within containers (e.g. toolbars or tool palettes), as well as reposition the containers themselves to facilitate physical access (e.g. to minimize hand travel on touch screens, or to facilitate preferred hand access on handheld mobile devices). | |||||
| AA | * Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls. | |||||
| AA | * Reset: The user has the option to reset the containers and controls to their default configuration. | |||||
| Guideline 2.9 - Allow time-independent interaction | ||||||
| Summary: Users can extend the time limits for user input when such limits are controllable by the user agent (2.9.1, Level A). | ||||||
| A | 2.9.1 Adjustable Time Limits: Where time limits for user input are recognized and controllable by the user agent, the user can extend the time limits. (Level A) | SB05: Re 2.9.1 (Adjustable Time Limits) "the user can extend the time limits", would it be a good idea to add "indefinitely"? Just in case some developer thinks "just let them have a 50% extension". | [done] UAWG: meeting 2014-02-06) decided that "indefinitely" was too much of a security risk. However, there was too much crossover with WCAG, so we changed 2.9.1 to bring it inline with WCAG and have it only apply to the UA user interface |
Partial accept |
Substantive |
Accepted |
| Guideline 2.10 - Help users avoid flashing that could cause seizures | ||||||
| Summary: To help users avoid seizures, the default configuration prevents the browser user interface and rendered content from flashing more than three times a second above luminescence or color thresholds (2.10.1, Level A), or even below the thresholds (2.10.2, Level AAA). | OP03: In Guideline 2.10 - Help users avoid flashing that could cause seizures
"To help users avoid seizures, the default configuration prevents the browser user interface and rendered content from flashing more than three times a second above luminescence or color thresholds (2.10.1, Level A), or even below the thresholds (2.10.2, Level AAA)." Maybe I'm not understanding this correctly, but I'm not sure how browsers could predict flashing content in a video and prevent it ahead of time. A lot of video on the web is in the form of a plugin (like flash) which is essentially sandboxed outside of the browser's direct control itself so even determining if that video is flashing is difficult at best. So this seems a bit overly difficult to actually implement in real life. Ultimately, I think it should be up to web authors to follow the WCAG guidelines regarding flashing content and including it here in the UAAG is not prudent. You *could* however, mention it here that user agents should not allow flashing content in the part of the UI like the browser chrome or the settings pages etc - though I think its improbable that browsers will ever do it on purpose as it is. |
[done] UAWG fixed the summary to remove "and rendered content". That was an artifact - the SC only apply to the User Agent User Interface. |
Accept |
substantive | ||
| A | 2.10.1 Three Flashes or Below Threshold: In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period, unless the flash is below general flash and red flash thresholds. (Level A) | |||||
| AAA | 2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period (regardless of whether not the flash is below the general flash and red flash thresholds). (Level AAA) | |||||
| Guideline 2.11 - Provide control of time-based media | ||||||
| Summary: The user can present placeholders for time-based media (2.11.1, Level A) and executable regions (2.11.2, Level A), or block all executable content (2.11.3, Level A), adjust playback (2.11.4, Level A), stop/pause/resume (2.11.5, Level A), navigate by time (2.11.6, Level A) or semantic structures such as chapter (2.1.7, Level AA), enable or disable tracks (2.11.8, Level AA), and adjust contrast and brightness of visual time-based media (2.11.9, Level AAA). | JO20: Rework of 'and' in a single clause:
Summary: The user can present placeholders for time-based media (2.11.1,
Level A) and executable regions (2.11.2, Level A), or block all
executable content (2.11.3, Level A), adjust playback (2.11.4, Level A),
stop/pause/resume (2.11.5, Level A), navigate by time (2.11.6, Level A)
or semantic structures such as chapter (2.1.7, Level AA), enable or
disable tracks (2.11.8, Level AA), adjust contrast and brightness of
visual time-based media (2.11.9, Level AAA). |
Accepted | ||||
| Summary: | LG01: I noticed an error in guideline 2.11. In the summary, each criterion is identified (e.g. stop/pause/resume 2.11.5). However there is a mismatch starting at 2.11.8. In the summary, 2.11.8 should describe enabling and disabling of tracks while 2.11.9 should address contrast adjustments. However in the following details section, there is no content about tracks, 2.11.8 is used to describe contrast and 2.11.9 is not listed. That criterion is very important because it likely address captions and audio description of timed media. |
[done] Action-986 | Accept | editorial | ||
| A | 2.11.1 Time-Based Media Load-Only: The user can override the play on load of recognized time-based media content such that the content is not played until explicit user request. (Level A) | |||||
| A | 2.11.2 Execution Placeholder: The user can request a placeholder instead of executable content that would normally be contained within an on-screen area (e.g. Applet, Flash), until explicit user request to execute. (Level A) | |||||
| A | 2.11.3 Execution Toggle: The user can turn on/off the execution of dynamic or executable content (e.g. Javascript, canvas, media). (Level A) | |||||
| AA | 2.11.4 Adjustable Playback Rate for Prerecorded Content: The user can adjust the playback rate of prerecorded time-based media content, such that all of the following are true: (Level AA) | |||||
| AA | * Playback Rate: The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time. | |||||
| AA | * Pitch: Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality. | |||||
| AA | * Synchronization: Audio and video tracks remain synchronized across this required range of playback rates. | |||||
| AA | * Reset: The user agent provides a function that resets the playback rate to normal (100%). | |||||
| A | 2.11.5 Stop/Pause/Resume Time-Based Media: The user can stop, pause, and resume rendered audio and animation content (e.g video, animation, changing text) that lasts three or more seconds at the default playback rate. (Level A) | |||||
| A | 2.11.6 Navigation of Time-Based media by Time: If time-based media lasts three or more seconds at the default playback rate, the user can navigate it using a continuous scale and by relative time units. (Level A) | |||||
| AA | 2.11.7 Navigation of Time-Based Media by Semantics: The user can navigate by semantic structure within the time-based media, such as by chapters or scenes present in the media. (Level AA) | |||||
| AAA | 2.11.8 Video Contrast and Brightness: Users can adjust the contrast and brightness of visual time-based media. (Level AAA) | |||||
| Guideline 2.12 - Support other input devices | ||||||
| Summary: User agents support all of the platform's text input devices (2.12.1, Level A), and for all input devices the user can input text (2.12.3, Level AAA) and perform all other functions (2.12.2, Level AA). | JO21: Is platform plural needed? The possessive clause is implied already.
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). |
Accepted | ||||
| A | 2.12.1 Platform Text Input Devices: If the platform supports text input using an input device, the user agent is compatible with this functionality. (Level A) | |||||
| AA | 2.12.2 Operation With Any Device: If an input device is supported by the platform, all user agent functionality other than text input can be operated using that device. (Level AA) | |||||
| AAA | 2.12.3 Text Input With Any Device: If an input device is supported by the platform, all user agent functionality including text input can be operated using that device. (Level AAA) | |||||
| PRINCIPLE 3: Ensure that the user interface is understandable | ||||||
| SH05: For the understandability principle, then isn't this a little all encompassing. There is nothing about simple language usage or graphic usage for people with a learning disability. So my question is understandable to whom? | [done] UAWG partially accepts. We note that SC5.1.1 already requires web-based user agents to meet parts of WCAG 2.0. We also added a note to 5.1.1, to encourage non-web-based user agent developers to follow WCAG 2.0. While there are aspects of understandability which are not addressed in UAAG20, UAWG chose to include items in Principle 3 that were both important and feasible. | Partial Accept | substantive | |||
| Guideline 3.1 - Help users avoid unnecessary messages | ||||||
| Summary: Users can turn off non-essential messages from the author or user-agent (3.1.1, Level AA). | CA01: We think this is excellent but can be open to misinterpretation. Authors will add content that is important to them (the author) but not important to the user, Examples include: Additional offers; how to upgrade to a more expensive option; downloading a toolbar etc. It should also be broader such as: Help users avoid and identify content that is not necessary to the task they are trying to perform. |
[done] UAWG decided to remove 3.1.1 because we could not find a way to make it testable. |
Not accepted |
substantive |
Accept See new comments -CA01 |
|
| AA | 3.1.1 Reduce Interruptions: The user can avoid or defer: (Level AA) | OP05: It's not clear what 'non-essential' means. It is highly subjective,
and would defer from web app to web app and from user to user. In
general, we try to make sure we ask as little from the user as
possible, but sometimes asking for permission is important. I'm not
sure on what criteria would compliance be judged with respect to
something being considered 'essential' or 'non-essential'.
|
[done] UAWG removed the term "non-essential" leaving low-priority. The SC uses the term 'recognized' which is explicitly limited to things that are objectively determinable, and in the example is WAI-ARIA markup that lets the author identify something as low priority. If UA followed aria-politeness recommendations it would pass UAWG removed 3.1.1. See CA01
|
Accept |
substantive |
|
| (a) Recognized messages that are non-essential or low priority | CA02: add item and reword a) Messages and content that are non-essential or low priority for the user b)Messages, features and content that are not part of the core use-cases for the content. c)Information in the user agent user interface that is being updated or changing d) d)Rendered content that is being updated or changing
|
[done] UAWG examined the testability of this SC and couldn't find a wording that was testable. Further, we could not find compelling use cases that would be testable. |
Not accepted |
substantive |
Accept | |
| (b) Information in the user agent user interface that is being updated or changing | CA03: Also we think it needs to be easy to do this - not just possible. So maybe add To ensure that it is easy to avoid or defer this content it should: Be not more then two steps, Such as: One step to select avoid or defer them and a conformation step. Only simple and clear text and symbols should be used in controls to avoid or defer this content Controls to avoid this type of content should be positioned above or next to the content that it refers to. Also the group is working to identify semantics that would make it possible to handle this as an adaptive interface at the user end. If this becomes possible and is supported, then it would be an acceptable alternative to make sure the Messages and content that are non-essential or low priority for the user and Messages, features and content that are not part of the core use-cases for the content can be programmatically identified. | [done] see discussion of CA01 |
Not accepted |
substantive |
Accept | |
| (c) Rendered content that is being updated or changing | UAWG notes that this would require visual blocking of ARIA politeness which is outside the ARIA spec. | |||||
| Guideline 3.2 - Help users avoid and correct mistakes | ||||||
| Summary: Users can have form submissions require confirmation (3.2.1, Level AA), go back after navigating (3.2.2, Level AA), have their text checked for spelling errors (3.2.3, Level AA), undo text entry (3.2.4, Level A), avoid or undo settings changes (3.2.5, Level A), and receive indications of progress activity (3.2.6, Level A). | CA04: Suggestion : Filling in information is much slower and harder for people with cognitive disabilities. Therefore: Information should be easily retrievable such as via automatically saving the work so far. The user should be able to go back a step without losing what they have submitted. People with cognitive difficulties often have very low confidence in the accuracy of what they are submitting and therefore the ability to review and amend easily is important. Also authors and agents should never try to confuse the user. For example, the users original selection / choice / offering should be selected by default not switched to the item they want to up-sell , such as expensive options being placed before the cheaper option that the user thinks they are selecting. (Obvious but worth spelling out anyway...). An example of this would be AVG antivirus that switches the user to premium edition and leaves it to the user to switch back. We would like to include: The original offering/selection should be selected by default and should not be switched automatically to an alternative If this is not acceptable maybe include: Label any alternatives clearly Make it easy to select the original offering: The original offering should be positioned above or next to the alternative The original offering should be sized the same or bigger then the the alternative In the future we may have the semantics that would make it possible to handle this as an adaptive interface at the user end. If this becomes possible then it would be an acceptable alternative to make sure the original selection can be programmatically identified.
|
[done] UAWG noted that most of this comment is related to web content not user agent user interface. Saving form information is an interesting possibility. Jan & Greg took an action to draft a possible SC. UAWG added a new success criteria for auto-fill of form fields. However UAWG notes that UAAG only applies to the user agent, and does not apply to content of web sites. That would be covered by WCAG. |
Partial accept |
substantive |
||
| AA | 3.2.1 Form Submission Confirm: The user can specify whether or not recognized form submissions must be confirmed. (Level AA) | |||||
| AA | 3.2.2 Back Button: The user can reverse recognized navigation between web addresses (e.g. standard "back button" functionality). (Level AA) | MS04 applies here. | [done] Added sentence to the Intent clarifying that this refers to the UA user interface. |
|||
| AA | 3.2.3 Spell Check: User agents provide spell checking functionality for text created inside the user agent. (Level AA) | MS04 applies here | [done] Changed "User agents" to "UA user interface" . |
|||
| A | 3.2.4 Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) | |||||
| Note: Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer. | ||||||
| A | 3.2.5 Settings Changes can be Reversed or Confirmed: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A) | |||||
| A | 3.2.6 Retrieval Progress: By default, the user agent shows the state of content retrieval activity. (Level A) | |||||
| Guideline 3.3 - Document the user agent user interface including accessibility features | CA05: Firstly , it should always be easy to ask / get help. Therefore: Help icon should be available to every screen that takes the user directly to relevant "how to use these features" or instructions Symbol for help should be used (such as a question mark) or the world "help" Getting help should not be hidden. For example it should not be under a menu of options. Any steps needed to get to help should have the word help or the question mark symbol clearly in it (such as "options and help"). Help text for core user tasks and main or essential features should be easy to understand. Help should be available in simple and clear text. Each step should be identified and labeled. Pictures that clarify what to do are recommended . We also would want to see a layered approach to help. Tooltip help is a wonderful memory aid for clarifying what user features are and particularly useful for people with an impaired working memory. We would add: Include short tooltips on all icons, jargon and shortened forms such as abbreviations. Typically these tooltips should be one or two words long. Tool tips in HTML can be provided via the title tag. (You many also want to indicate that the tooltip should be or at least include the accessible name, so that those who use voice control can use the tooltip to discover the accessible name) |
[done] UAWG added a new success criterion to document all the user interface features of the user agent. |
Accept |
substantive |
||
| Summary: User documentation is available in an accessible format (3.3.1, Level A), it includes accessibility features (3.3.2, Level A), delineates differences between versions (3.3.3, Level AA), provides a centralized view of conformance UAAG2.0 (3.3.4, Level AAA). | ||||||
| A | 3.3.1 Accessible Documentation: Product documentation is available in a format that meets success criteria of WCAG 2.0 level "A" or greater. (Level A) | |||||
| A | 3.3.2 Describe Accessibility Features: For each user agent feature that is used to meet UAAG 2.0, at least one of the following is true: (Level A) | |||||
| (a) Described in the Documentation: Use of the feature is explained in the user agent's documentation; or | ||||||
| (b) Described in the Interface: Use of the feature is explained in the user agent user interface; or | ||||||
| (c) Platform Service: The feature is a service provided by an underlying platform; or | ||||||
| (d) Not Used by Users: The feature is not used directly by users (e.g., passing information to a platform accessibility service). | ||||||
| AA | 3.3.3 Changes Between Versions: Changes to features that meet UAAG 2.0 success criteria since the previous user agent release are documented. (Level AA) | |||||
| AAA | 3.3.4 Centralized View: There is a dedicated section of the documentation that presents a view of all features of the user agent necessary to meet the requirements of User Agent Accessibility Guidelines 2.0. (Level AAA) | |||||
| Guideline 3.4 - Make the user agent behave in predictable ways | ||||||
| Summary: Users can prevent non-requested focus changes (3.4.1, Level A). | ||||||
| A | 3.4.1 Avoid Unpredictable Focus: The user can prevent focus changes that are not a result of explicit user request. (Level A) | |||||
| PRINCIPLE 4: Facilitate programmatic access | ||||||
| Guideline 4.1 - Facilitate programmatic access to assistive technology | ||||||
| Summary: The user agent supports platform accessibility services (4.1.1, Level A) that are quick and responsive (4.1.7, Level A), including providing information about all controls and operation (4.1.2, Level A & 4.1.6, Level AA), access to DOMs (4.1.4, Level A). Controls can be adjusted programmatically (4.1.5, Level A). Where something can't be made accessible, provide an accessible alternative version, such as a standard window in place of a customized window (4.1.3, Level A). | ||||||
| Note: UAAG 2.0 assumes that a platform accessibility API will be built on top of underlying security architectures that will allow user agents to comply with both the success criteria and security needs. | ||||||
| A | 4.1.1 Support Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A) | |||||
| A | 4.1.2 Expose Basic Properties: For all user interface components, including user agent user interface, rendered content, and generated content, the user agent makes available the following via a platform accessibility service: (Level A) | CA06: When possible make, sure the meaning and role of all interface components can be programmatically identified | [done] UAWG agrees on this very important principle and has worked this into all appropriate parts of UAAG. However, the user agent can only ask for existing attributes such as name, role, state, value, selection, and focus from the Accessibility API. "Meaning" can be inferred from the name, but there is no accessibility API attribute for "meaning". Otherwise, this is exactly what is intended with 4.1.2 |
Partial accept |
substantive |
|
| A | * Name | |||||
| A | * Role | |||||
| A | * State | |||||
| A | * Value | |||||
| A | * Selection | |||||
| A | * Focus | |||||
| A | 4.1.3 Provide Equivalent Accessible Alternatives: If a component of the user agent user interface cannot be exposed through platform accessibility services, then the user agent provides an equivalent alternative that is exposed through the platform accessibility service. (Level A) | |||||
| A | 4.1.4 Make DOMs Programmatically Available: If the user agent implements one or more Document Object Models (DOM), they must be made programmatically available to assistive technologies. (Level A) | |||||
| A | 4.1.5 Make Write Access Programmatically Available: If the user can modify the state or value of a piece of content through the user interface (e.g. by checking a box or editing a text area), the same degree of write access is programmatically available. (Level A) | |||||
| AA | 4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (Level AA) | |||||
| AA | * Bounding dimensions and coordinates | |||||
| AA | * Font family of text | |||||
| AA | * Font size of text | |||||
| AA | * Foreground and background color for text | |||||
| AA | * Change state/value notifications | |||||
| AA | * Highlighting | |||||
| AA | * Keyboard commands | |||||
| A | 4.1.7 Make Programmatic Exchanges Timely: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A) | SH06: 4.1.7 is about making API Calls be timely such that delays aren't perceived by users, but this is difficult if the software interfaced to us not timely, people may the perceive a delay. I think this needs to be a little more explicit. |
[done] UAWG agreed that the 4.1.7 was not testable in that there are so many variables that can impact response time; and the accessibility issures in response time are not ones that usually can be addressed by the user agent. 4.1.7 has been removed from UAAG 2.0. |
Accept |
substantive |
|
| PRINCIPLE 5: Comply with applicable specifications and conventions | ||||||
| Guideline 5.1 - Comply with applicable specifications and conventions | ||||||
| Summary: When the browser's controls are authored in HTML or similar standards, they need to meet W3C's Web Content Accessibility Guidelines (5.1.1, Levels A, AA, AAA). The user agent supports the accessibility features of content formats (5.1.2, Level A) and of the platform (5.1.3, Level A), allows handling of unrendered technologies (5.1.4, Level A) including by alternative viewers (5.1.5, Level AA), and allows users to report accessibility issues (5.1.6, Level AAA). | JO22: Remove "including by":
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)
alternative viewers (5.1.5, Level AA), and allows users to report
accessibility issues (5.1.6, Level AAA). |
[done] |
Accept |
editorial | Accepted | |
| A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria | 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria) | |||||
| Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). | ||||||
| A | 5.1.2 Implement Accessibility Features of Content Specifications: Implement the accessibility features of content specifications. Accessibility features are those that are either (Level A): * Identified as such in the content specifications or | |||||
| A | * Allow authors to satisfy a requirement of WCAG 2.0 | |||||
| Note 1: If a conformance claim is filed, cite the implemented specifications in the conformance claim. | ||||||
| Note 2: When a rendering requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. | ||||||
| A | 5.1.3 Implement Accessibility Features of the Platform: If the user agent contains non-web-based user interfaces, then those user interfaces follow user interface accessibility guidelines for the platform. (Level A) | |||||
| Note: When a requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. | ||||||
| AA | 5.1.5 Allow Content Elements to be Rendered in Alternative Viewers: The user can select content elements and have them rendered in alternative viewers. (Level AA) | |||||
| AAA | 5.1.6 Enable Reporting of User Agent Accessibility Faults: The user agent provides a mechanism for users to report user agent accessibility issues. (Level AAA) | |||||
Conditions on Conformance Claims |
||||||
If a conformance claim is made, the conformance claim must meet the following conditions: |
EH07: I believe that these word can be deleted. The bulleted list has already be introduced (“conditions and following information”). You might possibly want a different heading if you want to distinguish between regular conformance and limited conformance for extensions. In that case you might want to explain, “There are two kinds of conformance – regular and limited….” |
[done] | Accept | editorial | ||
Components of UAAG 2.0 Conformance Claims |
||||||
|
||||||
6. Platform: Provide relevant information about the software and/or hardware platform(s) that the user agent relies on for conformance. This information may include:
|
EH08: in f. "web" sometimes "web" is capitalized and other times it is not. |
[done] | Accept | editorial | ||
| 7. Platform Limitations: If the platform (hardware or operating system) does not support a capability necessary for a given UAAG 2.0 success criterion, list the success criterion and the feature (e.g. a mobile operating system does not support platform accessibility services, therefore the user agent cannot meet success criterion 4.1.2). For these listed technologies, the user agent can claim that the success criteria do not apply. | EH09: Not clear what technologies are being referred to? Are they the "feature[s]" referred to in the previous sentent? if so, then call them the same thing. It seems important to resolve this because it would be esy to confuse the not applicable technologies of this point with the the "Web Content Techologies" of the next point. |
[done] changed to "features" | Accept | editorial | ||
| 7. Platform Limitations: | EH10: What if there was a poor choice of platform? Do the success criteria still not apply? (I hope so, just want to make sure that this is the case.) | [done] We don't want to penalize user agents for deficiencies in the platform. In particular, user agents that are being deployed on multiple platforms should not be held responsible for deficiencies of the platform. | Answered | Question | ||
| 8. Web Content Technologies: List the web content technologies rendered by the user agent that are included in the claim. If there are any web content technologies rendered by the user agent that are @@excluded from the conformance claim@@, list these separately. Examples of web content technologies include web markup languages such HTML, XML, CSS, SVG, and MathML, image formats such as PNG, JPG and GIF, scripting languages such as JavaScript/EcmaScript, specific video codecs, and proprietary document formats. | EH11: Are claimants able to exclude any and all of the rendered technologies (at their own discretion). Or must they include a minimum of one rendered technology? Not clear.
|
[done] we did not want to set a minimum number of web technologies, because it would make it more complicated for mobile apps that wanted to follow UAAG.
|
Not accepted | editorial | ||
| 8. Web Content Technologies: | EH12: Is there any overlap between the list of features not supported in #7 and the Web content technologies excluded from the conformance claim? It is not clear. | [done] There could be. MathML is noted in both 7 & 8 as not implemented in the platform (#7) and being excluded as a technology in #8. | Answered | Question | ||
9. Declarations: For each success criterion, provide a declaration of either
|
EH13: What are the allowable reasons that a success criterion (for a certain conformance level) can be “not applicable.” Is the only allowable reason that the capability/feature is not supported (#7) or could it also be that the developer has chosen to exclude a web content technology from the claim (#8). Not clear. | [done] UAWG added three allowable reasons for success criteria being declared not applicable: (Conformance #9.b)
|
Accept | Substantive | ||
Limited Conformance for ExtensionsThis option may be used for a user agent extension or plug-in with limited functionality that wishes to claim UAAG 2.0 conformance. An extension or plugin can claim conformance for a specific success criterion or a narrow range of success criteria as stated in the claim. All other success criteria may be denoted as Not Applicable. The @@add-in@@ must not cause the combined user agent (hosting user agent plus installed @@extension or plug-in@@) to fail any success criteria that the hosting user agent would otherwise pass. |
EH14: Are add-in and extension the same thing? The glossary entry for “user agent extension” seems to imply as much. If so, then why not use the same term throughout? | [done] adjusted the terms for consistency. | Accept | editorial | ||
| Glossary | user agent extension (add-in)
|
EH15: Is a “user agent extension” the same as an “extension” and the same thing as an “add-in”. It is not clear. | [done] adjusted the terms in the definition for consistency | Accept | editorial |
Skip to Content 