Re: Comments on Web Content Accessibility Guidelines

Patrick Schmitz wrote:
> 
> 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.

We attempt to emphasize that good design produces accessible documents,
thus I don't think there's a conflict. However, if the tone leans
towards accessibility, I think that's to be expected from this document.
Nonetheless, I will review the language of the introduction.
 
> 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.

It is likely that the editors will adopt a clearer numbering convention.
 
> 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. 

We intend to provide this as a separate W3C Note.

>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.  

I'm not sure what you mean by strategies. Could you be more specific?
The prose at the beginning of section A discusses general
principles (these are not exactly strategies, admittedly) and the
checkpoints themselves are strategies for addressing the
guidelines. Perhaps a more implementation-oriented discussion
of strategies belongs in the techniques document. Any suggestions
are appreciated.

> 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.

This is another document that we intend to provide as a W3C Note.
 
> 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.

The Working Group has strong reservations about making
such a statement because of the difficulties raised by
alternative pages (see the Note after the checkpoints
in Guideline 13). Furthermore, the Working Group feels
that the checkpoint about alternative pages (13.5) should
be listed *after* the others of that guideline despite
the fact that it is a priority 1 checkpoint in order to
dissuade authors from using this solution as a first
option. Authors should attempt to make their pages
accessible, not separate but equal.
 
> 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.

Proposed text:

      Users with blindness will understand the function of 
      the image when the text is read aloud by a speech synthesizer.
 
> *       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.

Checkpoint 15.1 does not refer to the use of "title" as
a means of a creating a tool tip. Checkpoint 15.1 talks
about link phrases, which should be understandable out
of context, terse, meaningful, and device-independent.

The "title" attribute in HTML should be used to give advisory
information about the target of a link. This information
MAY be used as a tool-tip by a user agent, but this is
not required in any W3C specification. 

Do users need to be told that it's possible to interact
with a Web document? Isn't that so fundamental to the 
Web that it's not necessary to state for every link
that this link is meant to be interacted with?

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

Proposed change:

  * Why certain pages are not accessible to people with disabilities.
 
> section:  How the guidelines are organized
> 
> *       What exactly is the point of the section on "Conformance"? 

The goal is that when an author or site or tool says "We meet
the requirements set forth by the Web Content Accessibility
Guidelines", that "meet the requirements" is well-defined
and verifiable.

>  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?

Eric Hansen has sent some interesting suggestions [1]
about the conformance section that the Working Group
has not yet had the opportunity to review. I trust that
some of your questions will be addressed during that review.

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0295.html

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

I think that's a good observation. It should be it's own section.
(The section follows the preceding paragraphs since it relies on some
of the definitions in them.)
 
> 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.

It is interesting that you are associating the term "transformation" so
strongly with "style sheets". Does that connection come
from an XSL perspective?

Style sheets provide some of the solutions listed in the
guidelines, but others rely on proper use of markup,
organization of content and of an entire site, navigation
tools, etc. 

>  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).

As mentioned above, this is meant to be discussed in a
separate W3C Note.
 
> *       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.

Proposed change to 1.2:

  Provide text equivalents for all applets and other programmatic
objects
  that present visual 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...

These subjects are discussed in section 2.9 of the Techniques Document.
However, we will look further into a discussion of CSS2's aural
cascading style sheets and how they can control cueing, background
sounds, etc. The editors will also look into more information about
synchronization and SMIL.
 
> *       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).

Yes, the conflict must be clearly documented. We will also re-examine
checkpoint 13.1, which says to use the latest W3C technologies. 
The phrase "wherever possible" must be clarified. It may be more
appropriate to use CSS1 features, for example, than some CSS2 features
until CSS2 is more widely supported. It is crucial for authors
to ensure that whatever features they use transform gracefully,
and style sheets are designed to do so.
 
> *       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.

As confusing as it may sound, CSS allows you to
use relative units in absolute positioning (and you should). 
Thus, you may position an image to be offset by "3em" from
the top of its containing element. This is a fixed distance,
but is relative to the current font size, so it scales
nicely.

Thus, relative "units" should be used wherever possible.

Thank you for your comments,

- Ian Jacobs and Wendy Chisholm

-- 
Ian Jacobs (jacobs@w3.org) 
Tel/Fax: (212) 684-1814 
http://www.w3.org/People/Jacobs

Received on Friday, 12 March 1999 15:31:01 UTC