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

Reposting of RE: Request for Review: WCAG 2.0 Working Draft in a readable format

From: <Bengt.Farre@androtech.se>
Date: Thu, 24 Oct 2002 21:44:02 +0200
Message-ID: <3DB84D82.67E8AB68@androtech.se>
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

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

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

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 GMT

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