- From: Wendy A Chisholm <wendy@w3.org>
- Date: Mon, 04 Nov 2002 08:41:09 -0800
- 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 UTC