Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Difference between revisions of "UAAG review"

From Education & Outreach
Jump to: navigation, search
(Implementing UAAG: Added h3 for guideline 1.3)
(Implementing Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.: a^bout numbering notes)
Line 152: Line 152:
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li>
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li>
<li style="padding-bottom:0.5em;">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? <span style="color:#808080;">{Sylvie, 14 June}</span></li>

Revision as of 12:28, 14 June 2013

Nav: EOWG wiki main page




  • comment {name}
  • Not sure where to add this comment that applies to UAAG and Implmenting: I find the summaries of each guideline really useful. {Sylvie, 14 June}
  • 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. {Shawn, 3 June}
  • Would the sections on Relationships to ATAG and WCAG be better in the Implementing document? Also, is there a reason why the "Guidelines" heading and each of the "Principles" headings are all at heading level H2? {Bim 14 June}



  • comment {name}
  • Second sentence in abstract:
    "User agents include browsers and other types of software that retrieve and render Web content."
    It may be useful to indicate what "other types of software" is meant in addition to browsers.{Sylvie, June 13}
  • Second paragraph, second sentence: "technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities."
    Perhaps it should be made clearer that the responsibility for Braille rendering will need to remain a function of the assistive technologies. .{Bim, June 14}
  • 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". {Bim, June 14}


  • comment {name}


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

UAAG 2.0 Layers of Guidance

  • 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. {Wayne}
  • Agree with Wayne, this isn't easy to read. 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. {Bim 14 June}
  • The three different levels of conformance are not obvious to read, in particular level A. The way it is written, it makes believe that there is a highest level whereas the highest level is called A. therefore, it may be helpful to write that the lowest level is called A and the highest is called AAA.
    Text concerned: "Three levels of conformance meet the needs of different groups and different situations: A (lowest), AA, and AAA (highest). {Sylvie June 13}

UAAG 2.0 Supporting Documents

  • comment {name}

Components of Web Accessibility

  • comment {name}
  • 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? {Bim 14 June}

Levels of Conformance

  • comment {name}
  • I don't understand one of the "Factors that were considered in the process of determining the level to a success criterion", fourth bullet:
    "implementation difficulty – ranging from deterministic to inferential" {Sylvie, June 13}
  • Agree with Sylvie, plainer terms would make the meaning clearer and easier to translate. {Bim 14 June}

Definition of User Agent

  • 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? {Bim 14 June}

Modality Independence Principle

  • comment {name}

Relationship with WCAG 2.0

  • comment {name}
  • 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? {Sylvie, June 13}

Relationship with ATAG 2.0

  • comment {name}

Implementing UAAG

Overall (Implementing)

  • comment {name}
  • 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? {Sylvie, 14 June}
  • Examples: change some of the names to be more diverse {Shawn, 3 June}
  • CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. {Shawn, 3 June}
  • change "Return to Guideline" to @@ {Shawn, 3 June}

Introduction (Implementing)

  • comment {name}

Definition of User Agent (Implementing)

  • comment {name}
  • 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? {Bim 14 June}

Implementing Guideline 1.1 - Provide access to alternative content.

  • comment {name}
  • 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.
    Another example in intent of SC 1.2:
    "Some users with visual disabilities may wish to hide images in order to avoid those that are painful (such as those with high contrast)."
    {Sylvie, 14 June}
  • In 1.1.3 Configurable Alternative Content Defaults, first example:
    "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? {Sylvie, 14 June}
  • In Examples of Success Criterion 1.1.6, the disability of the users is not always specified, (e.g. Maximilian or Tom. {Sylvie, 14 June}

Implementing Guideline 1.2 - Repair missing content.

  • comment {name}
  • 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. {Sylvie, 14 June}

Implementing Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.

  • comment {name}
  • 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? {Sylvie, 14 June}