some comments...

A1.check 6:
replace ASCII art with an image and alternative text.

There are ways of marking up ASCII art, both with HTML and with natural
language content. These should be acceptable alternatives, but are not as
the checkpoint currently stands.

A4 check 2 and check 3:
I don't understand why providing an audio track of a movie is Priority 1
but a text track is priority 2. It seems to me on careful re-reading that
this checkpoint assume the previous guideline (provde text transcripts of
audio) but I think it should make that more explicit. In any case, it
should be a priority 1 - if there is an audio description the way to make
it accessible is by providing a text transcript of the description as well
as the dialogue.

A5 rationale:
Why is "users with devices that have non-colour or non-visual displays" in
parentheses? This is inconsistent with the rest of the document. (Wow,
I'm getting really pedantic here.)

A9 check 4.
I think that we should be recommending the use of CSS. We could suggest
that people might also want to use HTML format mark-up. I think that we
should state more clearly why tables should not be used, and then discuss
how they can be used in the techniques document. The basic issue is that
there are a group of people for whom table-based layout, except in certain
strictly defined circumstances, is inaccessible. And CSS does degrade
gracefully, although certain types of information can be lost - it is as
easy to misuse CSS to visually convey structure as it is to misuse
structural mark-up to achieve visual effects.

Also there should be a cross-ref to A13 check 5.

A8 check 1: 'Don't use structural markup (eg TH) with layout TABLEs'
I don't think it is P1 - perhaps P2 but more likely to be P3.

A10 rationale:
'This is particularly important for objects that contain text and does not
apply to instant redirection'

These are two seperate concepts being linked in what could easily be
misinterpreted as zeugma (Not very useful word for the day *grin*).
Replacing 'and' with 'but' would clarify a lot.

A12:
I think it is more complex than this. What I would like is the following:

Ensure that features of the page can be activated in ways that are not
device specific.

Rationale: (obvious)

General: in general it is sufficient to ensure keyboard access, as most
sytems allow other devices to provide control as if it were done from the
keyboard.

Checkpoint:
Use of mouse-specific triggers onMouseOver etc is not accessible, and some
alternative means of accessing the functionality is required.
Note: Hopefully this will be addressed in future versions of HTML and User
Agents. In particlar some mouse-based events such as onClick, as
interpreted by common browsers, could easily be replaced by non-device
specific events such as onActivate.

CMN This is important. These things simply do not work, and in some cases
it is likely that they never will. The fact that they are part of the HTML
spec means that we should explicitly recommend they not be used, otherwise
they will. (And are).

A13 check 5:
Why is this P2 not P1?

B2 check 4: 'Offer a site Map'
Should we discuss the particular problems of these? If they are visual
they are a nightmare, if they are a well-structured index to the site with
some underlying textual form which makes sense they are fantastic.



Generally, good job (as always)

Charles



--Charles McCathieNevile -  mailto:charles@w3.org
phone: * +1 (617) 258 0992 *  http://purl.oclc.org/net/charles
       **** new phone number ***
W3C Web Accessibility Initiative -  http://www.w3.org/WAI
545 Technology sq., Cambridge MA, USA

Received on Tuesday, 22 December 1998 19:09:46 UTC