Re: Web Content Accessibility Guidelines

Warner ten Kate wrote:
> I read the Web Content Accessibility Guidelines.
> I found it a useful and valuable document.

That's very encouraging.
> I have one comment in that the Introduction suggests
> the guidelines concern any type of access, ie. not
> only improvement of access by disabled persons, but
> also access through constrained devices or access
> under special circumstances.
> Although the guidelines can be used, and likely
> will be used, to improve presentation in such cases,
> I found that serving that purpose would cause me
> to reconsider some of the Priority ratings.
> Concerning resource constrained devices, those are
> designed as such, aiming to serve a certain application.
> It is a question in what level those devices require
> more comprehensible access, and when required, whether
> other solutions can be provided.
> As an example, I don't know whether a true long
> longdesc solves the display problems a mobile
> phone encounters with images.

Your point is well-taken. The introduction has been
designed to tell authors that designing with accessibility
in mind will help them produce pages that transform
gracefully in a number of situations. The priorities, however,
reflect needs of people with disabilities. While it may be
true that a Priority 1 checkpoint such as 1.1 ("Provide
text equivalents for all images") will benefit a number
of user classes, search robots, etc. , the priority
was assigned because of accessibility needs.
> As another example, when requiring captioning
> to assist audio streams, I am missing a guideline
> on the language of that captioning. I guess,
> implicitly, there is the assumption that the
> audio (and captioning) are authored for a certain
> target audience (speaking some language), of which
> a part is disabled in their sensory perception.

Can you explain what you mean by a "guideline
on the language of the captioning"? Do you mean
that the caption's natural language should be identified?
Although 6.2 comes close to covering 
this ("Identify the primary (natural) language of a document."), 
perhaps we need to add a checkpoint about identifying the natural
language of alternative content. There is also an "hreflang" attribute
in HTML for identifying the language of the target of a link.
Should that be included?
> As a final example, I would rate guideline 5.4
> (use style sheets to control layout and presentation)
> as Priority 1, when not considered in the context
> of access improvement for disabled.

> I am not stating the guidelines are not beneficial
> to the wider area, but I would suggest to restrict
> the scope of the Guidelines to access by disabled people
> more clearly (the Abstract does mention this).
> I expect doing this will help the understanding of
> the document and its use.

> Some minor things:
> - I found the section indexing "A", "B", "C" confusing.
>   I would number the sections and call the first appendix "A".

There have been many discussions about this, but I will raise
your point with the Working Group.

> - Where possible, try to circumvent the use of subjective rating
>   in the guidelines. Such use counters the rating by Priority index.
>   For example,
>   - "important" in guideline 2.1
>   - "if needed" in guideline 2.2
>   - "properly" in guideline 5.1

While I agree with you that we should avoid subject language,
the Working Group chose the wording for some checkpoints very
carefully. For example, checkpoint 2.1 uses the word "important"
intentionally (and links to its definition in the glossary). Not
every image needs a long description. We must rely on the user's
judgement to determine that an image (or applet, etc.) is important
enough that it deserves one.

As for "if needed" and "where possible", I agree that these
should be reviewed and deleted ... "where possible".

The term "properly" in 5.1 needs elaboration. The WG should
address, for example, whether a jump from an H2 to and H4 is
considered "properly nested" or whether such a jump
is permissible. (As opposed, for example, to an H3 preceding
and H2 when logically the first follows the second.)
> - I would rate longdescs as Priority 2, assuming that
>   that will encourage the use of 'title' and 'alt'.
>   I mean, I fear a risk, otherwise the guidelines are not
>   adhered and none of these get implemented.
>   Alternatively, the cases were longdesc is Priority 1
>   could be made more specific.

I think the Priority 1 is "tempered" by the notion of important.
The Working Group might consider lowering the Priority explicitly
for less important cases, as it did for checkpoint 10.1, which reads:

  [Priority 1 if information or functionality is important and not
  presented elsewhere, otherwise Priority 2.] 
> - checkpoint 4.1:
>   I agree with this one, but I like to mention that sometimes
>   color can enhance the message, but is acceptable when lost,
>   eg. upon printing (recall, that in such cases the device
>   can opt for other solutions to present the information).

Please explain how you would change the wording of the checkpoint:

   Ensure that all information conveyed with color is 
   also available without color, for example from context or markup.
> - checkpoint 5.1:
>   I was confused by the wording "nest". I understood that as, eg,

Yes, I agree that the editors need to state more clearly what is
meant in the case of HTML by "nested header".
>     <h1>
>        heading 1 text
>        <h2>nested header</h2>
>        remainder heading 1
>     </h1>
>   which isn't valid HTML.
>   I think the intended meaning is, eg,
>     <h1>heading 1 text</h1>
>        ...
>        <h2>nested header</h2>
>        ....
>     <h1>other heading 1</h1>
>    the "nesting" concerns the alignment with the
>    contextual organisation.
>    I find this is an interesting observation:
>    The content model of the heading elements doesn't reflect
>    this guideline. In fact, two informations are needed:
>    - structure of headings (ie. nesting as reffered in this guideline)
>    - the (text) data being in those headings (what h1-6 model)
>    A combined model could go in the direction of:
>     <section>
>        <h>heading 1 text</h>
>           <!-- heading 1 because of child of first section -->
>        ...
>        <section>
>           <h>nested header</h>
>              <!-- heading 2 because of child of second level section -->
>            ....
>        </section>
>        ....
>        <h>other heading 1</h>
>     </section>
>     where levels can be set (like numbers on a <li>)
>     Perhaps the guideline should read that the use of heading levels
>     should reflect the structural organisation of textual context.
>     (with an example to make this more clear.)

That's an elegant phrasing.
> Hope you find these comments of use,

Very much so. Thank you again,

 - Ian

Ian Jacobs ( 
Tel/Fax: (212) 684-1814

Received on Thursday, 11 March 1999 13:34:38 UTC