W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2014

Comments on UAAG 7 November 2013 Drafts

From: Shawn Henry <shawn@w3.org>
Date: Fri, 31 Jan 2014 16:32:51 -0600
Message-ID: <52EC2493.3010503@w3.org>
To: public-uaag2-comments@w3.org
CC: "EOWG (E-mail)" <w3c-wai-eo@w3.org>, Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr>

Below are comments from Sylvie Duchateau, Shawn Henry, Andrew Arch, and Sharron Rush.
Note: These comments are from individuals and have not been reviewed by all EOWG participants.

UAAG & Implementing UAAG:

* Change: "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.

* Abstracts: 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.)

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

Implementing UAAG – Overall:

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

* Typos: "webpage" instead of "web page". "timeline" vs. "time line"?

Abstract (Implementing):

* 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 <a href="http://www.w3.org/WAI/intro/uaag">User Agent Accessibility Guidelines (UAAG) Overview</a>.
(Wording also avoids "best practice recommendations" because it can be a problem in the legal area, according to Gregg V.)

Examples of Success Criterion 1.8.2:

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

Examples of Success Criterion 2.3.4:

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

Examples of Success Criterion 2.4.1:

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

Examples of Success Criterion 2.5.2:

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

* 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".


These are in addition to comments submitted in December 2013 <http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0006.html>.


Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
Massachusetts Institute of Technology (MIT)
e-mail: shawn@w3.org
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/
Received on Friday, 31 January 2014 22:32:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:29:49 UTC