- From: <Bengt.Farre@androtech.se>
- Date: Thu, 24 Oct 2002 21:44:02 +0200
- To: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
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 Page 7- 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………….” Page 10-Success Criteria Wording of this section is unwieldy and difficult to follow. Page 14- Success Criteria Could be useful to define what is meant by “seriously interfere” Page 15- Example 2 Missing value- assumed to be 20db for consistency. ‘Disambiguation’ is a bit ambiguous! Page 15- Success Criteria Is a definition of Unicode needed here? Page 17-Success Criteria 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. Page 18- Examples 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 Page 20- Benefits ‘Distractibility problems’ could be reworded to say ‘individuals who are easily distracted’. Page 21- Navigation Could be useful to have something about navigation through tables and frames? Page 21- Providing Structure 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. Page 23- Success Criteria Difficult to follow could be reworded? Page 25- 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. Page 27- 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. Page 29- Examples Not very clear from wording, this should be expanded as well. Page 31- 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. Page 35- Complex Information What is meant by ‘several layers’? Page 36- Reviewer 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.
Received on Thursday, 24 October 2002 15:48:00 UTC