Comments on Web Content Accessibility Guidelines

It is great to have a document like this, and I think that it has great
potential to improve web content with respect to accessibility.  As a guide
to toolmakers, it should help as well.  I do think that it strikes a tone
that design is not as important as accessibility, which may not go over too
well with some authors.

Overall, I agree with Warner on the section identification.  The Guidelines
appear to be the first appendix, rather than the heart of the document.  I
would just remove the "A." from this section header.

I also think that if the document will stand on its own, more background
information or points should be provided.  E.g. there should at least an
introduction to various devices commonly used to enhance accessibility, such
as screen readers. In addition, I think it would help if there was a more
general discussion of strategies to be employed, such as the use of
stylesheets to transform documents.  Perhaps a brief discussion of the
common use-cases would help: How a user with blindness typically browses the
web, and the same for users with hearing, cognitive, language impairments.
Many authors and designers have little or no understanding of the current
state of affairs in these cases.  

I think it would be worth mentioning up front that in some cases the best
approach will be to author an alternate page.  Various guidelines mention
this, but especially as relates to media-rich content, I think it worthwhile
to acknowledge that effective design for the different audiences often
requires alternate documents.



Running through the document start to end:

section:  Introduction

*	Intro section describing use of alt text as a benefit to users with
blindness:
	This would benefit from mention of screen readers or similar
technology.  To the reader without experience with such devices, the notion
of replacing an image with text to help users with blindness seems curious
at best.

*	Following point mentions use of altText in tooltips - this means a
loss of features for designers, who often use the tooltip text as an
invitation to interaction ("click here to learn more").  Guideline 15.1 says
not to use this at all, and yet interaction designers often recommend doing
this. 

*	Further down, bullet "Why certain pages are inaccessible".
Interesting word choice - "inaccessible" seems a bit strong and sounds like
a 404 synonym.

section:  How the guidelines are organized

*	What exactly is the point of the section on "Conformance"?  The
three requirements for claims of conformance are pretty vague - where should
these items be noted?  In comments?  In some meta-element? In a separate
document?

*	Why is the section on "Conformance" in a section on document
organization?

section:  Guidelines

*	The intro to this section introduces the notion of transformation of
documents.  This is a change from the tone of the intro.  Perhaps an
additional section on strategies/mechanisms for transformation of documents
would help to explain the underpinnings of the approaches.  If the
assumption is that stylesheets will be the basis for much of the
accessibility guidelines, then that should be stated.  Some additional
verbiage about or references to typical accessories that are used to enhance
accessibility (such as screen readers) would probably help many designers
who are less familiar with these issues (the link to the Braille display
definition is a good example).

*	Checkpoint 1.2 - this should perhaps be qualified to describe
programmatic elements that have a direct visual representation. Some objects
are added to extend the functionality of the page, but do not have any
specific associated visual element (they may manipulate the DOM for various
elements).  The alternates should concentrate on the presentation, rather
than on code that may play a part in presenting the information.

*	For media rich pages, some additional guidelines seem appropriate to
cover how audio should layer, especially when it is used for accessibility.
If music is playing on the page, how should this interact with an audio
alternative to a movie or animation?  How should audio cues added to buttons
add to this?  How do screen readers manage all the audio?  I know that I am
ignorant of what is available, but I think that especially in the area of
multimedia, some more guidance would probably be useful.  How does a screen
reader deal with text that interactively "pops up" somewhere as an
alternative to some graphic effect? Perhaps I just need to understand better
how screen readers are used...

*	Guideline 5 seems to be in conflict with the goal of supporting
users with downlevel browsers.  Several of the practices recommended against
are used because they are the most portable means of specifying a formatting
effect.  Not much we can do here, except note the conflict (as is done in
the techniques doc).

*	Guideline 5.6 says "Use relative rather than absolute units in
markup language attribute values ..." and then the techniques document says
in the layout section below "Layout, positioning, layering, and alignment
should be done through style sheets (notably by using CSS floats and
absolute positioning)".  Guideline 5.6 should perhaps be clarified to except
positioning attributes.



Thanks -  Patrick

Patrick Schmitz
Program Manager - HTML+TIME
Microsoft

Received on Thursday, 11 March 1999 19:03:28 UTC