W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2002

Fwd: RE: Request for Review: WCAG 2.0 Working Draft

From: Wendy A Chisholm <wendy@w3.org>
Date: Mon, 04 Nov 2002 08:41:09 -0800
Message-Id: <5.1.0.14.2.20021104083944.02416910@localhost>
To: w3c-wai-gl@w3.org

Comments from WWAAC via David Poulson and Colette Nicolle
Reposted with more detail.

>Comments on W3C -Web Content Accessibility Guidelines 2.0
>Working Draft 22 August 2002
>
>
>Some General Points
>
>Difficult to comment in detail as the technology specific checklists also
>need to be developed.
>
>No specific mention is made of the possible value of creating page abstracts
>and summaries to help those who have limited capacity for reading large
>amounts of text. Checkpoint 4.3 covers the annotation of 'complex,
>abbreviated or unfamiliar information with summaries and definitions', but
>this is not the same as using abstracts and summaries as a matter of course
>for all web pages. This could be particularly useful for symbol users or
>those with poor reading skills. Note: this is also related to the whole
>issue of providing meta content for pages that can be accessed if required,
>i.e. keywords, titles, abstracts.
>
>There could be more content on facilitating navigation through hyperlinks.
>Mention is made of ensuring labels are meaningful, but there may be other
>advice that could be useful e.g. numbers of links on pages, navigating
>hyperlinks, and how to refer to internal and external links.
>
>Could be worth looking at Microsoft's Accessibility Guidelines as well to
>see what else might be useful. The framework covering design principles may
>be particularly useful. The issue of multiple windows and how to control
>them may be worth considering in the section on Navigation (guideline 3).
>Also issue of the use of frames?
>
>The Overview of Design Principles is very clear and useful.
>
>Specific Comments
>
>Overview of Design Principles - User Needs
>
>First bullet point is slightly confusing. Better as" Someone who cannot hear
>will require auditory presented information transformed into a visual form"
>
>Second point- Slightly misleading as relatively few blind people read
>Braille, better as "Someone who cannot see or hear may want to read through
>Braille....."
>
>Also final point better as "Someone who does not read or see well
>may............."
>
>Checkpoint 1.2, minimum level success criteria #1
>Wording of this section is unwieldy and difficult to follow.
>
>Checkpoint 1.4, minimum level success criteria #1
>Could be useful to define what is meant by "seriously interfere"
>
>Checkpoint 1.4, Example 2
>Missing value- assumed to be 20db for consistency.
>
>Checkpoint 1.5, minimum level success criteria #1
>Is a definition of Unicode needed here?
>
>Checkpoint 1.5, minimum level success criteria #2
>'Disambiguation' is a bit ambiguous!
>
>Checkpoint 2.1, minimum level success criteria #1
>Could be made clearer i.e. user agents and event handlers may be too
>technical for some readers. Checkpoint 2.1 is particularly difficult to
>follow.
>
>Checkpoint 2.1, Benefits
>The illustrated benefit is probably not such a good example as speech input
>is only appropriate in a limited number of cases. A better example would be
>that keyboard mapping for functions allows specialist switch input devices
>to work with the applications
>
>Checkpoint 2.3, Benefits
>'Distractibility problems' could be reworded to say 'individuals who are
>easily distracted'.
>
>Guideline 3, Navigable
>Could be useful to have something about navigation through tables and
>frames?
>
>Checkpoint 3.1, success criteria
>Could be useful to include top loading of page content here as well, i.e.
>putting most important information or summaries of content at the top of
>pages.
>
>Checkpoint 3.2, success criteria
>Difficult to follow could be reworded?
>
>Checkpoint 3.3,  Definitions: site navigation mechanisms
>Could also mention use of 'breadcrumb trails' to assist site navigation.
>I.e. providing information on pages to show the individual where they have
>come from in the structure of the site.
>
>Checkpoint 3.5, Consistent and predictable responses
>Could be worth adding something about consistent labelling of controls and
>functions performed in different parts of the application.  Even though this
>would most probably fit under the 'Operable' Guideline, it is still also
>relevant here. Point is not clearly made.
>
>Checkpoint 3.5, Examples
>Not very clear from wording, this should be expanded as well.
>
>Guideline 4, Understandable
>The issue of top loading page content could also be raised again here.
>
>The WWAAC project is working on specific success criteria and advisory
>recommendations for making the content understandable for people with
>communication or cognitive impairments.
>
>Checkpoint 4.3, Examples of complex information
>What is meant by 'several layers'?
>
>Checkpoint 5.1, Reviewer's note
>If I understand this point correctly, well formed code (following protocols)
>is important for accessibility as it can make it easier for alternative
>browsers to decode web content. For example, I believe this one of the
>arguments for xhtml to be used instead of html.

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Monday, 4 November 2002 11:30:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:20 GMT