UAAG 2.0 text based on "WD-UAAG20-20130523.txt" dated Thu Jun 6 13:43:44 2013.
Education & Outreach Working Group (EO)
Jan Richards & Anastasia Chetham (OCAD)
Andrew Robertson (AR)
Alan Smith (AS)
John Foliot (JF)
Priority | Guidelines and Success Criteria | Comments | Type | Response | Disposition | Acknowledgement |
---|---|---|---|---|---|---|
Introduction and material before the guidelines. | Working Draft of UAAG 2.0JF1: I believe that UAAG would have more impact if it employed RFC 2119 language, over vaguer instructions such as “can” and “it is recommended”. Definition of Compliance LevelAR1: It isn't fair or indicative if a user agent is genuinely compliant in all AA or AAA criteria yet has to be regarded as non-compliant overall if only one level A criteria is non-compliant. This is another reason why exemptions for platform limitation changes should not just include hardware and OS, but the development platform where the author is not the user agent's vendor. Overall (Implementing)EO1: Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing. EO2: Would the sections on Relationships to ATAG and WCAG be better in the Implementing document? EO3: Also, is there a reason why the "Guidelines" heading and each of the "Principles" headings are all at heading level H2? EO23: (Implementing) Would it be possible to use structuring elements such as H5s to indicate sections like Intent of SC, Examples and resources? While comparing to the structure of Understanding WCAG 2.0, is there a W3C graphical design that could make each guideline document look similar? EO24: (Implementing) Examples: change some of the names to be more diverse EO25: (Implementing) CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. EO26: (Implementing) change "Return to Guideline" to @@ AbstractEO4: Second sentence in abstract: EO5: Second paragraph, second sentence: "technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities." EO6: Third paragraph, has a couple of errors in the acronyms: "the W3C" has "W3C" expanded to "the World Wide Web Consortium", so the word "the" is in both plain and title text (this happens elsewhere on the page too); "Web Accessibility Initiative" is written in full but its acronym is also expanded (incorrectly), so the output is "Web Accessibility Initiative the Web Access Initiative". EO7: First paragraph: it's not clear to me what "...and through other internal facilities..." means IntroductionEO8: "This section is informative." Should change this to a header: "Informative Section". Other alternatives: reword it to "The section that follows is informative or add a colon so that readers know what follows is information. Otherwise, it's not clear cwhat "this" means - does it refer to the section that follows or the section that the hyperlink points to? OverviewEO9: Suggest changing: "Accessibility involves a wide range of disabilities." to "Accessibility involves consideration of a wide range of disabilities." EO10: May be the Working Group can bring more clarifications on the second sentence of follwoing paragraph, give an example of features concerned: EO11: The fourth paragraph seems like it could be a set of bullet points:
In such cases, UAAG 2.0 assumes that features required by UAAG 2.0 will be built on top of an underlying security architecture. " Layers of Guidance EO12: I would link from the 3 bullet items - Principles, Guidelines, Success Criteria - to where readers can read the specifics of each of these items - i.e. where they can read the 5 "principles" EO: 13: The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading Principles 4 and 5 are new and need more than just naming. The meaning of facilitate programmatic access and comply with specifications and conventions is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear. EO14: Perhaps a nested list would help too because separation (and therefore an understanding) of principles 4 and 5 is complicated by the need to use the word "and" twice so closely together. On first reading this sounded like one principle to me. EO15: The three different levels of conformance are not obvious to read, in particular level A. The way it is written, it makes believe that there is a highest level whereas the highest level is called A. therefore, it may be helpful to write that the lowest level is called A and the highest is called AAA. EO16: First paragraph includes the following items "...explanatory intent, examples and resource links." The way this section is written, I expected these items to have their own bullet points. If these items don't get their own bullets (or possibly are meant to be included under the bullet "success criteria"), then the first paragraph needs to be rewritten to reflect this meaning. UAAG 2.0 Supporting DocumentsEO17: (referred to as the "Implementing document" from here on) should probably read as (hereafter referred to as the "Implementing document") Components of Web AccessibilityEO18: As this section directly references ATAG and WCAG, perhaps it should be followed by the sections that explain the relationship between UAAG and the other two sets of guidelines. Perhaps even move the "Relationship" sections into the Implementing document and link to them? Levels of ConformanceEO19: I don't understand one of the "Factors that were considered in the process of determining the level to a success criterion", fourth bullet: EO20: plainer terms would make the meaning clearer and easier to translate. Definition of User Agent (Implementing)AR2: There should also be a distinction between s/w developed by a vendor vs s/w developed in-house using a platform purchased from a vendor. EO21:This appears to be identical to the "Definition of a User Agent" in the Implementing document. Could it be tersified in one or the other? EO22: I had trouble with the What Qualifies section. The word order tends to make it more confusing than it needs to be. I understand that we need to include procedural as well as declarative languages, but is there any other kind of programming language. Are you making your point? Are you trying to say no programming language is excluded as a basis for generating user interface? What qualifies as a User Agent?These guidelines employ the following tests to determine if software qualifies as a user agent. UAAG 2.0 divides potential user agents into
If the following three conditions are met, then a platform-based application is a user agent:
Example Qual-1: A standard browser. If the following two conditions are met then an extension or plug-in is a user agent:
Example Qual-2: Any media player or browser enhancing extension.
Example Qual-3: Don't have one. I think the confusion in this section springs from lack of examples, and this also springs from the lack of example of a web-app UA in implementing. The distinction between a general web app and a web app UA is not defined clearly, and maybe the concept is not well defined. That is, perhaps a web-app behaves like a UA sometimes and not at others EO26: (Implementing) Third paragraph: the link to "What Qualifies as a User Agent" is followed by the name of the current document in brackets, isn't this redundant? EO27: I think comment from "Modality Independence Principle" is appropriate here. I like that they use easy-to-follow if-then conditions, but examples are needed for clarity. Modality Independence PrincipleEO22.1: I thought I was going crazy until I noticed that the anchor in the TOC reads "Modality Independence Principle," while the section it links to is titled "Modality Independent Controls" These are very different things. I personally think this section is ok, just need to change the anchor link to "Modality Independent Controls." Relationship with WCAG 2.0EO23.1: The relationship between UAAG and WCAG is not very clear: when the application is considered to be a user agent and when not. As WCAG applies in both cases, why is it mentionned here? |
JF1 [@@done] - Action-861
AR1 [needs proposal] Action-846
EO1: editorial
EO2: [@@done][editorial] EO3: [@@done][editorial] we didn't want to lose a level of heading for 1 item. EO23: [not addressed] [editorial] Jeanne will fix code
EO24: [editorial] Kim will generate new names as we work. EO25: [editorial][not addressed] with EO23 EO26: [editorial] [not addressed]Jeanne will fix code EO4: [editorial] [@@ done] browsers, media players and applications EO5: [editorial] [@@ done](e.g. assistive technologies for braille rendering)
EO6 [editorial] [@@ done]
EO7 [editorial] [@@ done]removed phrase
EO8 [editorial] [@@ done]
EO8 [editorial] [@@ done]
EO10 & EO11: [@@ done][needs proposal] added note in 4.1 (include EO11)
EO12: [@@ done] [needs proposal]
EO13 [@@ done] [needs proposal] Action- 856
EO14 [@@ done] [needs proposal] Action- 856
EO15 [needs proposal] Action- 849
EO16 [needs proposal] Action- 849
EO17 [editorial] [@@ done]
EO18 [editorial] [@@ done]
EO19 [editorial] [@@ done]
EO20 [editorial]
AR2: software developed in-house should have to follow guidelines as well. EO21: [editorial] [@@ done] - EO22: [editorial] [@@ done] - approve changes to #2 in extension/plugin
EO22.1: [editorial] [@@ done] Action-860
EO23.1: [editorial] [@@ done] |
JF1- proposal not accepted
eo12 Proposal not accepted
|
|||
PRINCIPLE 1 - Ensure that the user interface and rendered content are perceivable | ||||||
Guideline 1.1 - Provide access to alternative content. | ||||||
Summary: The user can choose to render any type of alternative content available. (1.1.1). The user can also choose at least one alternative such as alt text to be always displayed (1.1.3), but it's recommended that users also be able to specify a cascade (1.1.5), such as alt text if it's there, otherwise longdesc, otherwise filename, etc. It's recommended that the user can configure the caption text and that text or sign language alternative cannot obscure the video or the controls (1.1.4). The user can configure the size and position of media alternatives (1.1.6). |
|
|||||
A | 1.1.1 Render Alternative Content: For any content element, the user can choose to render any types of recognized alternative content that are present. (Level A) | OCAD1: Is the phrase "For any content element " necessary? ...BTW: did the group ever look at this proposal (of mine)?: http://lists.w3.org/Archives/Public/w3c-wai-ua/2011AprJun/0086.html JF2: is there something that speaks to this use-case: <abbr title=”World Wide Consortium”>W3C</abbr>?) |
OCAD1 - [@@ done] reworded "The user can choose to render any type of recognized alternative content that are present for a content element." JF2 - [needs proposal] we will consider adding an example in the Implementation guide for <acronym>. |
[accepted] | ||
Note: It is recommended that the user agent allow the user to choose whether the alternative content replaces or supplements the original content element. | ||||||
A | 1.1.2 Replace Non-Text Content: The user can have all recognized non-text content replaced by alternative content, placeholders, or both. (Level A) | EO29: (Implementing) Several occurences in this guideline and may be elsewhere through the doc: in Intent of success criterion X, the document says that non text content is unusable, or "painful". I have never seen this term elsewhere in W3C docs and wonder if it is appropriate. OCAD2 Seems kind of extreme at Level A that the user should have the option to view captions with the video not displayed at all. |
EO29: [editorial][@@ done]
OCAD2: [@@ done] reworded The note addresses that they can supplement. That covers captions. |
[accepted]
[accepted] |
||
Note: At level A, the user agent can specify that an alternative content or placeholder replace the non-text content. At level AA success criterion 1.1.3 requires that the user can specify one format or placeholder to be used. At level AAA success criterion 1.1.5 requires that the user can specify a cascade order of types of alternative content to be used. | ||||||
AA | 1.1.3 Configurable Alternative Content Defaults: For each type of non-text content, the user can specify a type of alternative content that, if present, will be rendered by default. (Level AA) | EO13: (implementing)
"Sally is blind. In the browser's preferences dialog box, Sally specifies that she wants alt text displayed in place of images, and that the document should reflow to allow the entire alt text to be displayed rather than truncated." As screen readers retrieve the alt text content is it necessary for a blind user to request that the browser displays alt text rather than images? May be the example should be rewritten to reflect real use of alt text by blind users?
|
Editorial | EO13: [@@ done][ change to low vision
|
[accepted] | |
AA | 1.1.4 Display of Alternative Content for Time-Based Media: For recognized on-screen alternative content for time-based media (e.g. captions, sign language video), the following are all true: (Level AA) (a) Don't obscure primary media: The user can specify that displaying time-based media alternatives doesn't obscure the primary time-based media; and (b) Don't obscure controls: The user can specify that the displaying time-based media alternatives doesn't obscure recognized controls for the primary time-based media; and (c) Use configurable text: The user can configure recognized text within time-based media alternatives (e.g. captions) in conformance with 1.4.1. | OCAD3 (a) seems like a lot at AA, especially since captions typically overlay the lower portion of the video. Others make sense. | OCAD3: [@@ done] reword |
[accepted] | ||
Note: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size to meet this requirement. | ||||||
AAA | 1.1.5 Default Rendering of Alternative Content (Enhanced): For each type of non-text content, the user can specify the cascade order in which to render different types of alternative content when preferred types are not present. (Level AAA) | OCAD4 Specifying the cascade would seem to lead to a confusing UI. Better to have a quick way to view all the options if the preferred one isn't available. | OCAD4: [@@ done] deleted | |||
AAA | 1.1.6 Size and Position of Time-Based Media Alternatives: The user can configure recognized alternative content for time-based media (e.g. captions, sign language video) as follows: (Level AAA) (a) The user can resize alternative content for time-based media up to the size of the user agent's viewport. (b) The user can reposition alternative content for time-based media to at least above, below, to the right, to the left, and overlapping the primary time-based media. | EO29.1: (Implementing) In Examples of Success Criterion 1.1.6, the disability of the users is not always specified, (e.g. Maximilian or Tom OCAD5 This is a lot of configurability. OCAD6: Right-and-left is a challenge with horizontally flowing languages like English. |
EO29.1 [editorial] [@@ done] Action-860 OCAD5: [@@ done] reworded OCAD6: [@@ done] reworded |
|||
Note 1: Depending on the screen area available, the display of the primary time-based media may need to be reduced in size or hidden to meet this requirement. | ||||||
Note 2: Implementation may involve displaying alternative content for time-based media in a separate viewport, but this is not required. | ||||||
Guideline 1.2 - Repair missing content. | ||||||
Summary: The user can request useful alternative content when the author fails to provide it. For example, showing metadata in place of missing or empty (1.2.1) alt text. The user can ask the browser to predict missing structural information, such as field labels, table headings or section headings (1.2.2). | EO28: (implementing) Link to definition of metadata would be helpful |
[J & K think it is a common term that has no special UAAG meaning] |
||||
AA | 1.2.1 Support Repair by Assistive Technologies: If text alternatives for non-text content are missing or empty then both of the following are true: (Level AA) (a) the user agent does not attempt to repair the text alternatives with text values that are also available to assistive technologies. (b) the user agent makes metadata related to the non-text content available programmatically (and not via fields reserved for text alternatives). | OCAD7: ATAG SC on which this was once based is now more clear (B.2.3.2)...rules out "No Generic or Irrelevant Strings: Generic strings (e.g. "image") and irrelevant strings (e.g., the file name, file format) are not used as text alternatives" EO30: Implementing) Why is a link to "Website Accessibility Conformance Evaluation Methodology" a resource for this particular guideline. I followed the link which brought me to the very top of the Evaluation Methodology Document but I had no idea what I should be looking for or which section to look at. (WCAG-EM) 1.0 EO31: (Implementing) I think an example of what's stated not to do in a & b would be helpful. Otherwise, I'm not exactly sure what those instructions are warning against. |
OCAD7 [needs proposal]
EO30 [editorial] [@@ done]
EO32 [needs proposal] |
|||
AAA | 1.2.2 Repair Missing Structure: The user can specify whether or not the user agent should attempt to insert the following types of structural markup on the basis of author-specified presentation attributes (e.g.. position and appearance): (Level AAA) (a) Labels (b) Headers (e.g. heading markup, table headers) | EO32: (Implementing) Examples of Success Criterion 1.2.2, first example: The example talks about Franck who is called George in the next sentence. ^Try to check that the names remain the same in each example, in order to avoid confusing the reader. |
EO32 [editorial] [@@ done] | |||
Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links. | ||||||
Summary: The user can visually distinguish selected, focused, and enabled items, and recently visited links (1.3.1), with a choice of highlighting options that at least include foreground and background colors, and border color and thickness (1.3.2). | ||||||
A | 1.3.1 Highlighted Items: The user can specify that the following classes be highlighted so that each is uniquely distinguished: (Level A) (a) selection (b) active keyboard focus (indicated by focus cursors and/or text cursors) (c) recognized enabled input elements (distinguished from disabled elements) (d) elements with alternative content (e) recently visited links | EO34: (Implementing) It would be nice to know that more info is available in "Examples of Success Criterion 1.3.1:" for note items 1 & 2. I don't know if there's a way to indicate this without cluttering up the screen. EO 35: (Implementing) missing word: In second bullet item under "Examples of Success Criterion 1.3.1": "so he tell where" should be "so he can tell where" EO36: (Implementing) 1st example under "Examples of Success Criterion 1.3.1:". When you refer to "website that uses styles to override visited link color", do you mean font style - such as italic in lieu of a "visited link color." If so, I think you should refer to it specifically as "font style" because style in a css file can include color. In any case, the current sentence is too ambiguous. EO37: (Implementing) missing word: Second sentence: "they working" should be "they are working" EO38 (Implementing) Should "hover" be included in the list of 1.3.1 classes where highlighting is user controlled? Or would this be the same as "selection"? EO29.2: (Implementing) SC 1.3.1 has three notes. I wonder if it is worth numbering them in note 1, note 2 ... or may be it does not make sense? |
EO34 J&K think that there is not a need to do this. The notes and examples are co-located. EO35 [editorial] [@@ done] EO36 [editorial] [@@ done]
EO37 [editorial] [@@ done] EO38 [editorial] needs group approval EO29.2 [editorial] [@@ done] |
EO: 34[proposal not accepted] | ||
AA | 1.3.2 Highlighting Options: When highlighting classes specified by 1.3.1 Highlighted Items, the user can specify highlighting options that include at least: (Level AA) (a) foreground colors, (b) background colors, and (c) borders (configurable color, style, and thickness) | EO33: (Implementing) more white space is needed above Section 1.3.2 and now that I'm looking at this more closely, greater line space is needed throughout between paragraphs and bullet items and above subheadings. OCAD8: This seems like too much configurability, especially if the user agent developer has chosen highlighting styling to maximize visibility within the widest variety of possible content situations. Fluid UIOptions for example enlarges input fields and makes images underlined and bold. |
[editorial]
[needs proposal] |
|||
Guideline 1.4 - Provide text configuration. | ||||||
Summary: The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2). | EO39: Typo: not sure whether we should indicate them in EOWG comments: Summary contains one word "the" that should not be there:
"The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2). |
|||||
A | 1.4.1 Configure Rendered Text: The user can globally set any or all of the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults: (Level A) (a) text scale (the general size of text) (b) font family (c) text color (foreground and background) (d) line spacing (e) character spacing | |||||
A | 1.4.2 Preserving Size Distinctions: The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. headers continue to be larger than body text). (Level A) | |||||
Guideline 1.5 - Provide volume configuration. | ||||||
Summary: The user can adjust the volume of each audio track relative to the global volume level (1.5.1). | ||||||
A | 1.5.1 Global Volume: The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. (Level A) | OCAD51: Seems like a lot for A. Maybe AA. | OCAD51: [@@ done] [survey] set to AA | |||
Guideline 1.6 - Provide synthesized speech configuration. | AS1 there should be a section in 1.6 covering the ability to quickly and easily switch speech synthesis language. (http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Jun/0000.html for proposal) | [@@ done] Group agreed to add 1.6.5 | ||||
Summary: If synthesized speech is produced, the user can specify speech rate and volume (1.6.1), pitch and pitch range (1.6.2), and synthesizer speech characteristics like emphasis (1.6.3) and features like spelling (1.6.4). | EO40: grammar/style: "and synthesizer speech characteristics like emphasis (1.6.3) and features like spelling (1.6.4)." "like" should be replaced with "such as" if meaning here includes features such as "emphasis" and "spelling". If the features are similar to "emphasis" and "spelling" but different, then "like" would be used | [editorial] | ||||
A | 1.6.1 Speech Rate, Volume, and Voice: If synthesized speech is produced, the user can specify the following: (Level A) (a) speech rate, (b) speech volume (independently of other sources of audio), and (c) voice, when more than one voice option is available | |||||
AA | 1.6.2 Speech Pitch and Range: If synthesized speech is produced, the user can specify the following if offered by the speech synthesizer: (Level AA) (a) pitch (average frequency of the speaking voice), and (b) pitch range (variation in average frequency) | |||||
Note: Because the technical implementations of text to speech engines vary (e.g., formant-based synthesis or concatenative synthesis), a specific engine may not support varying pitch or pitch range. A user agent will expose the availability of pitch and pitch range control if the currently selected or installed text to speech engine offers this capability. | ||||||
AAA | 1.6.3 Advanced Speech Characteristics: The user can adjust all of the speech characteristics offered by the speech synthesizer. (Level AAA) | |||||
AA | 1.6.4 Synthesized Speech Features: If synthesized speech is produced, the following features are provided: (Level AA) (a) user-defined extensions to the synthesized speech dictionary, (b) "spell-out", where text is spelled one character at a time, or according to language-dependent pronunciation rules, (c) at least two ways of speaking numerals: spoken as individual digits and punctuation (e.g. "one two zero three point five" for 1203.5 or "one comma two zero three point five" for 1,203.5), and spoken as full numbers are spoken (e.g. "one thousand, two hundred and three point five" for 1203.5), (d) at least two ways of speaking punctuation: spoken literally, and with punctuation understood from natural pauses. | |||||
Guideline 1.7 - Enable Configuration of User Stylesheets. | ||||||
Summary: The user agent shall support user stylesheets (1.7.1) and the user can choose which if any user-supplied (1.7.2) and author-supplied (1.7.3) stylesheets to use. The user agent will allow users to save user stylesheets (1.7.4). | EO41: (Implementing) 3rd bullet under "Examples of Success Criterion". 2nd occurrence of word "text" should be removed. EO42: (Implementing) similar problem with 4th bullet under "Examples of Success Criterion". "text easiest to read text if text is highlighted" should be changed to: "text easiest to read if it is highlighted"
|
[editorial]
[editorial] |
||||
A | 1.7.1 Support User Stylesheets: If the user agent supports a mechanism for authors to supply stylesheets, the user agent also provides a mechanism for users to supply stylesheets. (Level A) | EO43: (Implementing) I wonder if it would be useful to explain acronyms such as in last "Examples of Success Criterion 1.7.1, 1.7.2 & 1.7.3".
explain what is ADHD? Is it clear to any reader?
|
[editorial] | |||
A | 1.7.2 Apply User Stylesheets: If user style sheets are supported, then the user can enable or disable user stylesheets for: (Level A) (a) all pages on specified websites, or (b) all pages | |||||
A | 1.7.3 Author Style Sheets: If the user agent supports a mechanism for authors to supply stylesheets, the user can disable the use of author style sheets on the current page. (Level A) | |||||
AA | 1.7.4 Save Copies of Stylesheets: The user can save copies of the stylesheets referenced by the current page, in order to edit and load the copies as user stylesheets. (Level AA) | |||||
Guideline 1.8 - Help users to use and orient within windows and viewports. | EO45: The meaning of this heading in not clear. Does "use" refer to "windows & viewport" as in "help users to use windows and viewports"? Suggest something like "Help users to orient within, and control, windows and viewports" | [editorial] | ||||
Summary: The user agent provides programmatic and visual cues to keep the user oriented. These include highlighting the viewport (1.8.1), keeping the focus within the viewport (1.8.2 & 1.8.7), resizing the viewport (1.8.3), providing scrollbar(s) that identify when content is outside the visible region (1.8.4) and which portion is visible (1.8.5), changing the size of graphical content with zoom (1.8.6 & 1.8.12), restoring the focus and point of regard when the user returns to a previously viewed page (1.8.8). Users can set a preference whether new windows or tabs open automatically (1.8.9) or get focus automatically (1.8.10). Additionally, the user can specify that all view ports have the same user interface elements (1.8.11), if and how new viewports open (1.8.9), and whether the new window automatically gets focus (1.8.10). The user can mark items in a webpage and use shortcuts to navigate back to marked items. (1.8.13). | EO44: Summary is long on this item. Readability would be improved if it was broken up into bullet items. |
[editorial] | ||||
A | 1.8.1 Highlight Viewport: The viewport with the input focus is highlighted and the user can customize attributes of the highlighting mechanism (e.g. shape, size, stroke width, color, blink rate). The viewport can include nested viewports and containers. (Level A) | OCAD9: Maybe highlighting customization part should be AA? | OCAD9: see resolution [@@ done] | |||
A | 1.8.2 Move Viewport to Selection and Focus: When a viewport's selection or input focus changes, the viewport's content moves as necessary to ensure that the new selection or input focus location is at least partially in the visible portion of the viewport. (Level A) | |||||
A | 1.8.3 Resize Viewport: The user can resize graphical viewports within the limits of the display, overriding any values specified by the author. (Level A) | OCAD10: Maybe AA? I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? | OCAD10: [@@ done] [survey] Action-862 | OCAD10: proposal accepted | ||
A | 1.8.4 Viewport Scrollbars: When the rendered content extends beyond the viewport dimensions, users can have graphical viewports include scrollbars, overriding any values specified by the author. (Level A) | |||||
A | 1.8.5 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level A) | AS2 (Implementing) 1.8.5 and 1.8.6 have the same $$Ally text and they should be slightly different | [editorial] | |||
A | 1.8.6: Zoom: The user can rescale content within graphical viewports as follows: (Level A) (a) Zoom in: to at least 500% of the default size; and (b) Zoom out: to at least 10% of the default size, so the content fits within the height or width of the viewport. | OCAD11: I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? | OCAD11: [survey] reword | Pending A or AA | ||
A | 1.8.7 Maintain point of regard: To the extent possible, the point of regard remains visible and at the same location within the viewport when the viewport is resized, when content is zoomed or scaled, or when content formatting is changed. (Level A) | |||||
AA | 1.8.8 Viewport History: For user agents that implement a viewport history mechanism (e.g. "back" button), the user can return to any state in the viewport history that is allowed by the content, including a restored point of regard, input focus and selection. (Level AA) | EO46: In "Examples of Success Criteria 1.8.8, 1.8.9 & 1.8.10:", first example talking about Justin, there is a word repetition: "The word remains selected remains the same so he doesn't have to reorient or find it on the page." OCAD12: I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport? Wording if we should group together top-level viewport SCs for clarity. |
[editorial]
[needs proposal] |
|||
AA | 1.8.9 Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA) | |||||
AA | 1.8.10 Do Not Take Focus: If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open. (Level AA) | |||||
AA | 1.8.11 Same UI: The user can specify that all top-level viewports (e.g. windows or tabs) follow the defined user interface configuration. (Level AA) | |||||
AA | 1.8.12 Reflowing Zoom: The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA) | OCAD13: usual wording is specify rather than "request". BTW all of the "specifies" make it sound like a lot of settings are required....could some be rewritten in the form: "When reflowable content in a graphical viewport is rescaled, it can be reflowed so that one dimension of the content fits within the height or width of the viewport." | OCAD13: [@@ done] [survey] Action-863 | OCAD13: [proposal accepted] | ||
Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap). | ||||||
AAA | 1.8.13 Webpage Bookmarks: The user can mark items in a webpage, then use shortcuts to navigate back to marked items. The user can specify whether a navigation mark disappears after a session, or is persistent across sessions. (Level AAA) | |||||
Guideline 1.9 - Provide alternative views. | ||||||
Summary: The user can view the source of content (1.9.2), or an outline view of important elements. (1.9.1). | EO47: For 1.9 should "or" in header ("The user can view the source of content (1.9.2), or an outline view of important elements. (1.9.1).") be "and/or" or simply "and"? Current wording seems to imply you should only do one or the other. | [editorial] | ||||
AA | 1.9.1 Outline View: Users can view a navigable outline of rendered content composed of labels for important elements, and can move focus efficiently to these elements in the main viewport. (Level AA) | |||||
Note: The important elements depend on the web content technology, but may include headings, table captions, and content sections. | ||||||
AAA | 1.9.2 Source View: The user can view all source text that is available to the user agent. (Level AAA) | EO48: (Implementing) The examples of Success Criterion 1.9.2 talk about users who display the source code of a page to find out what an untagged image is for or to modify style sheets. I am not sure that these examples are realistic as users need to have knowledge of code to have a look at lines of source codes. Either the group should explain that these users have already good knowledge of page coding, or the examples should be rewritten. @@Eowg thoughts on this are welcome. See for example the users' reactions in Jaws 14 who can set their screen reader to start reading on a specific place (h, div, and so on) on the page or ignore iframes (like facebook iframes). They are disturbed by the use of code to set this. |
[needs proposal] | |||
Guideline 1.10 - Provide element information. | ||||||
Summary:The user agent presents information about content relationships (e.g. form labels, table headers)(1.10.1), and extended link information (e.g. title, internal vs. external) (1.10.2) | EO50: I know what you're saying in the summary but I wonder if there's a better phrase than "content relationship" - perhaps "content hierarchy" or "content metadata" or "parent/sibling relationships." | [editorial] | ||||
AA | 1.10.1 Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA) | EO49 (Implementing) Same comment as EO48 for example of success criterion 1.10.2, where the user "selects the text he's interested in, opens the browser's debug window, which shows him that the selected text is an element with class "story" inside a paragraph inside a DIV with class "Premiere". He then knows the combination of classes and element types to specify in the user style sheet.". | [editorial] | |||
AAA | 1.10.2 Access to Element Hierarchy: The user can determine the path of element nodes going from the root element of the element hierarchy to the currently focused or selected element. (Level AAA) | OCAD14: This one say "can determine". Same as "can access"? | [editorial] | |||
PRINCIPLE 2. Ensure that the user interface is operable | ||||||
Guideline 2.1 - Ensure full keyboard access. | ||||||
Summary: Users can operate all functions (2.1.1), and move focus (2.1.2) using just the keyboard. Users can activate important or common features with shortcut keys, (2.1.6), override keyboard shortcuts in content and user interface (2.1.4), escape keyboard traps (2.1.3), specify that selecting an item in a dropdown list or menu not activate that item or move to that new web page (2.1.4) and use standard keys for that platform (2.1.5). | ||||||
A | 2.1.1 Keyboard Operation: All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A) | |||||
A | 2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times. (Level A) | EO51 (Implementing) example 1: Two names have been used for first example: Amal and Alan. OCAD15: Is this still needed with 1.8.1 and 1.8.8? |
[editorial] [needs proposal] |
|||
A | 2.1.3 No Keyboard Trap: If keyboard focus can be moved to a component using a keyboard interface (including nested user agents), then focus can be moved away from that component using only a keyboard interface. If this requires more than unmodified arrow or tab keys (or other standard exit methods), users are advised of the method for moving focus away. (Level A) | |||||
A | 2.1.4 Separate Selection from Activation: The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author content. (Level A) | EO52 (Implementing) last example refers to a specific device and screeen reader (Iphone and Voiceover). Is it ok to do that, or should the document remain device and screen reader neutral?
"Ari uses Voiceover on his iPhone to navigate a webpage. He selects an item and is able to activate the element using gestures. This requires sufficient screen real estate to perform gestures without changing focus." |
[editorial] | |||
A | 2.1.5 Follow Text Keyboard Conventions: The user agent follows keyboard conventions for the operating environment. (Level A) | OCAD16: Does "author content" need a definition? Sometimes also says "author supplied" | [needs proposal] | |||
A | 2.1.6 Efficient Keyboard Access: The user agent user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level A) | |||||
Guideline 2.2 - Provide sequential navigation | ||||||
Summary: Users can use the keyboard to navigate sequentially (2.2.3) to all the operable elements (2.2.1) in the viewport as well as between viewports (2.2.2). Users can optionally disable wrapping or request a signal when wrapping occurs (2.2.4). | ||||||
A | 2.2.1 Sequential Navigation Between Elements: The user can move the keyboard focus backwards and forwards through all recognized enabled elements in the current viewport. (Level A) | |||||
A | 2.2.2 Sequential Navigation Between Viewports: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A) | |||||
A | 2.2.3 Default Navigation Order: If the author has not specified a navigation order, the default sequential navigation order is the document order. (Level A) | |||||
A | 2.2.4 Options for Wrapping in Navigation The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can request notification when such wrapping occurs. (Level AA) | OCAD17: Should this be AA? Missing ":". Also, wording feels odd (allow it to be turned off, alert when it is done). | [editorial] [survey] A-> AA |
|||
Guideline 2.3 - Provide direct navigation and activation | ||||||
Summary: Users can navigate directly (e.g. keyboard shortcuts) to important elements (2.3.1) with the option of immediate activation of the operable elements (2.3.3). Display commands with the elements to make it easier for users to discover the commands (2.3.2 & 2.3.4). The user can remap and save direct commands (2.3.5). | ||||||
AA | 2.3.1 Direct Navigation to Important Elements: The user can navigate directly to any important elements (e.g. structural or operable) in rendered content. (Level AA) | OCAD18: Maybe remove "any" and the e.g....it is really important the reader views the definition. | [editorial] | |||
AA | 2.3.2 Present Direct Commands from Rendered Content (enhanced): The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email). (Level AA) | OCAD19: Says "Enhanced" but there is no minimum. Prefer to have just one e.g. per sentence rather than two. | [editorial] | |||
A | 2.3.3 Direct activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A) | OCAD20: Perhaps AA? | [survey] | |||
AA | 2.3.4 Present Direct Commands in User Interface: The user can have any direct commands in the user agent user interface (e.g. keyboard shortcuts) be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) | OCAD21: Again, prefer just one e.g. | [editorial] | |||
AA | 2.3.5 Customize Keyboard Commands: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. The user must be able to save these settings beyond the current session. (Level AA) | OCAD22: Save requirement should be removed as it is covered by 2.7.1. Also the single-key and key-plus-modifier text seems like overkill. | [needs proposal] | |||
Guideline 2.4 - Provide text search. | ||||||
Summary: Users can search rendered content (2.4.1) forward or backward (2.4.2) and can have the matched content highlighted in the viewport (2.4.3). The user is notified if there is no match (2.4.4). Users can also search by case and for text within alternative content (2.4.5). | ||||||
A | 2.4.1 Text Search: The user can perform a search within rendered content (e.g. not hidden with a style), including rendered text alternatives and rendered generated content, for any sequence of printing characters from the document character set. (Level A) | EO53 (Implementing) In "Examples of Success Criterion 2.4.1:"
OCAD23: Can e.g. be removed?
|
[editorial]
[editorial] |
|||
A | 2.4.2 Find Direction: The user can search forward or backward in rendered content. (Level A) | |||||
A | 2.4.3 Match Found: When a search operation produces a match, the matched content is highlighted, the viewport is scrolled if necessary so that the matched content is within its visible area, and the user can search from the location of the match. (Level A) | EO54 (Implementing) In Examples of Success Criterion 2.4.3: "Jules is low vision and uses a magnified screen." Better write: "Jules has low vision and uses a magnified screen." | [editorial] | |||
A | 2.4.4 Alert on Wrap or No Match: The user can be notified when there is no match to a search operation. The user can be notified when the search continues from the beginning or end of content. (Level A) | |||||
AA | 2.4.5 Search alternative content: The user can perform text searches within textual alternative content (e.g. text alternatives for non-text content, captions) even when the textual alternative content is not rendered onscreen. (Level AA) | |||||
Guideline 2.5 - Provide structural navigation. | ||||||
Summary: Users can view (2.5.1), navigate (2.5.2), and configure the elements used in navigating (2.5.3) content hierarchy. | ||||||
AA | 2.5.1 Location in Hierarchy: When the user agent is presenting hierarchical information, but the hierarchy is not reflected in a standardized fashion in the DOM or platform accessibility services, the user can view the path of nodes leading from the root of the hierarchy to a specified element. (Level AA) | OCAD24: How is this related to 1.10.2? | [needs proposal] | |||
AA | 2.5.2 Navigate by structural element: The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA) (a) by heading (b) within tables | OCAD25: How is this related to 1.10.1? AS3 (Implementing) has "inpu" which should be "input" |
[needs proposal] [editorial] |
|||
AAA | 2.5.3 Configure Elements for Structural Navigation: The user can configure sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA) | OCAD26: "configure sets of" implies ability to create multiple sets | [needs proposal] | |||
Guideline 2.6 - Provide access to event handlers | ||||||
Summary:Users can interact with web content by mouse, keyboard, voice input, gesture, or a combination of input methods. Users can discover what event handlers (e.g. onmouseover) are available at the element and activate an element's events individually (2.6.1). | ||||||
AA | 2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner. (Level AA) | OCAD27: User can discover? | [needs proposal] | |||
Guideline 2.7 - Configure and store preference settings | ||||||
Summary: Users can restore preference settings to default (2.7.2), and accessibility settings persist between sessions (2.7.1). Users can manage multiple sets of preference settings (2.7.3), and adjust preference setting outside the user interface so the current user interface does not prevent access (2.7.4). It's also recommended that groups of settings can be transported to compatible systems (2.7.5). | ||||||
A | 2.7.1 Persistent Accessibility Settings: User agent accessibility preference settings persist between sessions. (Level A) | OCAD28: Maybe reword to use the term "saved" | [editorial] | |||
A | 2.7.2 Restore all to default: The user can restore all preference settings to default values. (Level A) | |||||
AA | 2.7.3 Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA) | EO55 (Implementing) In last example of SC 2.7.3: "At those times he users his browser's user preference profiles to load a different configuration that’s optimized for the keyboard." Write: "He uses his keyboard" | [editorial] | |||
AA | 2.7.4 Change preference settings outside the user interface: The user can adjust any preference settings required to meet the User Agent Accessibility Guidelines (UAAG) 2.0 from outside the user agent user interface. (Level AA) | OCAD29: AAA perhaps? EO56 (Implementing)
|
[survey]
[editorial] |
|||
AAA | 2.7.5 Portable Preference Settings: The user can transfer all compatible user agent preference settings between computers. (Level AAA) | OCAD30: "computers" sounds outdated. | [editorial] "devices" |
|||
Guideline 2.8 - Customize display of GUI controls | ||||||
Summary: It's recommended that users can add, remove and configure the position of graphical user agent controls and restore them to their default settings (2.8.1). | ||||||
AA | 2.8.1 Customize display of controls representing user interface commands, functions, and extensions: The user can customize which user agent commands, functions, and extensions are displayed within the user agent's user interface as follows:(Level AA) (a) Show: The user can choose to display any controls available within the user agent user interface, including user-installed extensions. It is acceptable to limit the total number of controls that are displayed onscreen. (b) Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some control). (c) Reposition: The user can choose to reposition individual controls within containers (e.g. Toolbars or tool palettes), as well as reposition the containers themselves to facilitate physical access (e.g. To minimize hand travel on touch screens, or to facilitate preferred hand access on handheld mobile devices). (d) Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls. (e) Reset: The user has the option to reset the containers and controls to their original configuration. | EO57 (Implementing) In Examples for SC 2.8.1:
OCAD31: This SC is probably twice as long as the next biggest. Has a different feel. |
[editoral]
[needs proposal] |
|||
AA | 2.8.2 Reset Toolbar Configuration: | EO58 there is only one title of 2.8.2 reset Toolbar configuration, and no text in it. OCAD32 this is an orphan handle |
[editorial] | |||
Guideline 2.9 - Allow time-independent interaction. |
||||||
Summary: Users can extend the time limit for user input when such limits are controllable by the user agent (2.9.1); by default, the user agent shows the progress of content in the process of downloading (2.9.2). | ||||||
A | 2.9.1 Adjustable Timing: Where time limits for user input are recognized and controllable by the user agent, the user can extend the time limits. (Level A) | |||||
A | 2.9.2 Retrieval Progress: By default, the user agent shows the progress of content retrieval. (Level A) | OCAD33: I think this is in the wrong GL, it doesn't allow time-independent interaction | [needs proposal] | |||
Guideline 2.10 - Help users avoid flashing that could cause seizures. | ||||||
Summary: To help users avoid seizures, the default configuration prevents the browser user interface and rendered content from flashing more than three times a second above a luminescence or color threshold (2.10.1), or does not flash at all (2.10.2). | ||||||
A | 2.10.1 Three Flashes or Below Threshold: In its default configuration, the user agent does not display any user interface components or recognized content that flashes more than three times in any one-second period, unless the flash is below the general flash and red flash thresholds. (Level A) | OCAD34: This is good for the User Agent UI, but hard to automatically determine in playing content. Perhaps 2.11.1 handles this? | [needs proposal] | |||
AAA | 2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components or recognized content that flashes more than three times in any one-second period (regardless of whether not the flash is below the general flash and red flash thresholds). (Level AAA) | OCAD35: Could this also then be removed? (related to comment OCAD34) | [needs proposal] | |||
Guideline 2.11 - Provide control of content that may reduce accessibility. | ||||||
Summary: The user can present placeholders for time-based media (2.11.1) and executable regions (2.11.2), or block all executable content (2.11.3); adjust playback (2.11.4), stop/pause/resume (2.11.5), navigate, (2.11.6) and specify tracks for prerecorded time-based media (2.11.8); and adjust contrast and brightness of visual time-based media (2.11.9). | ||||||
Applicability Notes: Guideline 2.11 and its success criteria only apply to images, animations, video, audio, etc. that the user agent can recognize. | ||||||
A | 2.11.1 Time-Based Media Load-Only: The user can override the play on load of recognized time-based media content such that the content is not played until explicit user request. (Level A) | EO59 (Implementing) In the first examples of Success Criterion 2.11.1: one word repeated: "Jill is blind. She browses browses the web using a screen reader to listen to the text of web pages." |
[editorial] | |||
A | 2.11.2 Execution Placeholder: The user can render a placeholder instead of executable content that would normally be contained within an on-screen area (e.g. Applet, Flash), until explicit user request to execute. (Level A) | EO 60 (Implementing) In Intent of Success Criterion 2.11.2 : last sentence of the note before examples: placholder instead of placeholder. EO 61 (Implementing) Examples of SC 2.11.2:
|
[editorial]
[editorial]
|
|||
A | 2.11.3 Execution Toggle: The user can turn on/off the execution of executable content that would not normally be contained within a particular area (e.g. Javascript). (Level A) | |||||
A | 2.11.4 Playback Rate Adjustment for Prerecorded Content: The user can adjust the playback rate of prerecorded time-based media content, such that all of the following are true: (Level A) (a) The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time. (b) Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality. (c) Audio and video tracks remain synchronized across this required range of playback rates. (d) The user agent provides a function that resets the playback rate to normal (100%). | OCAD36: Could this be AA? | [survey] | |||
A | 2.11.5 Stop/Pause/Resume Time-Based Media: The user can stop, pause, and resume rendered audio and animation content (including video, animated images, and changing text) that last three or more seconds at their default playback rate. (Level A) | OCAD37: 3 seconds seems weirdly short | [@@done]Taken from WCAG wording. No change. | |||
A | 2.11.6 Navigate Time-Based Media: The user can navigate along the timebase using a continuous scale, and by relative time units within rendered audio and animations (including video and animated images) that last three or more seconds at their default playback rate. (Level A) | OCAD38: 3 seconds seems weirdly short | [@@done]Taken from WCAG wording. No change. | |||
AA | 2.11.7 Semantic Navigation of Time-Based Media: The user can navigate by semantic structure within the time-based media, such as by chapters or scenes present in the media. (Level AA) | |||||
AA | 2.11.8 Track Enable/Disable of Time-Based Media: During time-based media playback, the user can determine which tracks are available and select or deselect tracks, overriding global default settings, such as captions or audio descriptions. (Level AA) | OCAD39: Both the examples in the implementing document are taken care of by something in GL1.1? So perhaps this can be removed. | [needs proposal] | |||
AAA | 2.11.9 Video Contrast and Brightness: Users can adjust the contrast and brightness of visual time-based media. (Level AAA) | |||||
Guideline 2.12 - Other Input Devices | ||||||
Summary: For all input devices supported by the platform, the user agents should let the user perform all functions aside from entering text (2.12.2), and enter text with any platform-provided features (2.12.1). If possible, it is also encouraged to let the user enter text even if the platform does not provide such a feature (2.12.3). | ||||||
A | 2.12.1 Support Platform Text Input Devices: If the platform supports text input using an input device, the user agent is compatible with this functionality. (Level A) | |||||
AA | 2.12.2 Operation With Any Device: If an input device is supported by the platform, all user agent functionality other than text input can be operated using that device. (Level AA) | |||||
AAA | 2.12.3 Text Input With Any Device: If an input device is supported by the platform, all user agent functionality including text input can be operated using that device. (Level AAA) | |||||
PRINCIPLE 3: Ensure that the user interface is understandable | ||||||
Guideline 3.1 - Help users avoid unnecessary messages. | ||||||
Summary: Users can turn off non-essential messages from the author or user-agent. | ||||||
AA | 3.1.1 Reduce Interruptions: The user can avoid or defer recognized non-essential or low priority messages and updating/changing information in the user agent user interface and rendered content. (Level AA) | OCAD40: Maybe remove "and rendered content". Only mechanism for this in content would seem to be politeness level and implementing that is should following the content spec. | [survey] | |||
Guideline 3.2 - Help users avoid and correct mistakes. | ||||||
Summary: Users can have form submissions require confirmation (3.2.1), go back after navigating (3.2.2), and have their text checked for spelling errors (3.2.3). | ||||||
AA | 3.2.1 Form Submission: The user can specify whether or not recognized form submissions must be confirmed. (Level AA) | |||||
AA | 3.2.2 Back Button: The user can reverse recognized navigation between web addresses (e.g. standard "back button" functionality). (Level AA) | |||||
AA | 3.2.3 Provide spell checking functionality: User agents provide spell checking functionality for text created inside the user agent. (Level AA) | |||||
A | 3.2.4 Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) | |||||
Note: Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer. | ||||||
A | 3.2.5 Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A) | |||||
Guideline 3.3 - Document the user agent user interface including accessibility features. | ||||||
Summary: User documentation is available in an accessible format (3.3.1), it includes accessibility features (3.3.2), delineates differences between versions (3.3.3), provides a centralized views of conformance UAAG2.0 (3.3.4), and is available as context sensitive help in the UA (3.3.5). | ||||||
A | 3.3.1 Accessible documentation: The product documentation is available in a format that meets success criteria of WCAG 2.0 Level "A" or greater. (Level A) | OCAD41: "conforms to least WCAG 2.0 Level A. | [editorial] | |||
A | 3.3.2 Document Accessibility Features: All features of the user agent that meet User Agent Accessibility Guidelines 2.0 success criteria are documented. (Level A) | OCAD42: The corresponding ATAG2 SC was rewritten: http://www.w3.org/WAI/AU/ATAG20/#sc_a421 | [needs proposal] | |||
AA | 3.3.3 Changes Between Versions: Changes to features that meet UAAG 2.0 success criteria since the previous user agent release are documented. (Level AA) | |||||
AAA | 3.3.4 Centralized View: There is a dedicated section of the documentation that presents a view of all features of the user agent necessary to meet the requirements of User Agent Accessibility Guidelines 2.0. (Level AAA) | |||||
Guideline 3.4 - The user agent must behave in a predictable fashion. | ||||||
Summary: Users can prevent non-requested focus changes (3.4.1). | ||||||
A | 3.4.1 Avoid unpredictable focus: The user can prevent focus changes that are not a result of explicit user request. (Level A) | OCAD43: This seems like the superset (and so the possible replacement) of 1.8.9 and 2.1.4. | [needs proposal] | |||
PRINCIPLE 4: Facilitate programmatic access | ||||||
Guideline 4.1 - Facilitate programmatic access to assistive technology | ||||||
Summary: Be compatible with assistive technologies by supporting platform standards (4.1.1), including providing information about all menus, buttons, dialogs, etc. (4.1.2, 4.1.6), access to DOMs (4.1.4), and access to structural relationships and meanings, such as what text or image labels a control or serves as a heading (4.1.5). Where something can't be made accessible, provide an accessible alternative version, such as a standard window in place of a customized window (4.1.3). Make sure that that programmatic exchanges are quick and responsive (4.1.7). | ||||||
A | 4.1.1 Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A) | |||||
A | 4.1.2 Name, Role, State, Value, Description: For all user interface components including user interface, rendered content, generated content, and alternative content, the user agent makes available the name, role, state, value, and description via platform accessibility services. (Level A) | OCAD44: Isn't this implementation detail for 4.1.1? | [survey] | |||
A | 4.1.3 Accessible Alternative: If a component of the user agent user interface cannot be exposed through platform accessibility services, then the user agent provides an equivalent alternative that is exposed through the platform accessibility service. (Level A) | |||||
A | 4.1.4 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (Level A) | |||||
A | 4.1.5 Write Access: If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically. (Level A) | OCAD45: Still isn't possible for ARIA as far as I know. | [needs proposal] | |||
A | 4.1.6 Expose Accessible Properties: If any of the following properties are supported by the platform accessibility services, make the properties available to the accessibility platform architecture: (Level A) (a) the bounding dimensions and coordinates of onscreen elements (b) font family of text (c) font size of text (d) foreground color of text (e) background color of text. (f) change state/value notifications (g) selection (h) highlighting (i) input device focus (j) direct keyboard commands (k) underline of menu items (keyboard command/shortcuts) | OCAD46: Why is this split from 4.1.2? | [needs proposal] | |||
A | 4.1.7 Timely Communication: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A) | |||||
PRINCIPLE 5: Comply with applicable specifications and conventions | ||||||
Guideline 5.1 - Comply with applicable specifications and conventions. | ||||||
Summary: When the browser's menus, buttons, dialogs, etc. are authored in HTML or similar standards, they need to meet W3C's Web Content Accessibility Guidelines. | ||||||
AAA | 5.1.1 WCAG Compliant: Web-based user agent user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level AAA) | OCAD47: Might want to remove Level AAA since it will be hard to find implementations. | [survey] | |||
Note: This success criterion does not apply to non-Web-based user agent user interfaces, but does include any parts of non-Web-based user agents that are Web-based (e.g. help systems). | ||||||
A | 5.1.2 Implement accessibility features of content specs: Implement and cite in the conformance claim the accessibility features of content specifications. Accessibility features are those that are either (Level A): (a) Identified as such in the specification or (b) Allow authors to satisfy a requirement of WCAG | OCAD48: This is central to the whole thing and it seems buried here. | [needs proposal] | |||
A | 5.1.3 Implement Accessibility Features of platform: If the user agent contains non-web-based user interfaces, then those user interfaces follow user interface accessibility guidelines for the platform. (Level A) | |||||
A | 5.1.4 Handle Unrendered Technologies: If the user agent does not render a technology, the user can choose a way to handle content in that technology (e.g. by launching another application or by saving it to disk). (Level A) | OCAD49: Is this an accessibility issue? | [survey] | |||
AA | 5.1.5 Alternative content handlers: The user can select content elements and have them rendered in alternative viewers. (Level AA) | OCAD50: Why is this AA if this user agent does a good job of making them accessible? | [followup] explain no change | |||
AAA | 5.1.6 Enable Reporting of User Agent Accessibility Faults: The user agent provides a mechanism for users to report user agent accessibility issues. (Level AAA) | |||||
Applicability Note: When a rendering requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. |