W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 1999

Re: Some comments on AU techniques

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 14 Sep 1999 18:50:21 -0400 (EDT)
To: Ian Jacobs <ij@w3.org>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.10.9909141828560.21556-100000@tux.w3.org>
my comments scattered, marked CMN - Ian's marked IJ

On Tue, 14 Sep 1999, Ian Jacobs wrote:

  I haven't finished reading the AU techniques document 
  that's part of last call [1] but I wanted to send 
  these comments anyway. I will reserve most editorial comments
  for another review.
  1) The document contains very little in the way of
     explanatory prose. This means that I think it will
     not help a reader unless that reader is a very
     informed developer. I think that this draft contains
     sufficient information for the Guidelines to become
     a Recommendation, but I think the Techniques document
     needs to be restructured with more prose, more
     explanations, and more rationale. 
I agree that further explanations and rationale would be good. It would also
perhaps provide a way of distinguishing the techniques document from the
guidelines document.

  2) Under checkpoint 1.1:
     a) Bullet 1: Provide options for accessibility 
     information such as equivalent alternatives to be 
     included whenever an object is added to a document. 
     I think the case of alternative text should be singled
     out. I think "such as" weakens a technique
     since the reader has no other place to turn at this point.
     There should be concrete examples in place of generalities.

I would prefer to provide a number of other alternatives, or to include (for
example) the sections from teh sample implementations. In fact I would like
those to be part of the general techniques as well as being available

    b) Bullets 3 and 4 refer to WCAG 1.0 Guidelines and Techniques.
       However, these are covered by checkpoint 1.2, so I suggest
       moving these techniques to checkpoint 1.2
    c) I think techniques for W3C languages should be listed 
       clearly, as in:
       * Accessibility of HTML
       * Accessibility of CSS
       * Accessibility of SMIL
       The current wording obscures this.
I agree

  3) Under checkpoint 1.2
     There should be no techniques in this checkpoint other than
     references to WCAG 1.0. I feel quite strongly about this
     since attempts to include information will necessarily be
     incomplete and risk deviating from WCAG 1.0. If the working
     group has suggested techniques, those should be sent
     to WCAG.

I am happy with that proposal
  4) Under checkpoint 1.3
     a) Template is undefined in the checkpoint text.
     b) Please refer to "navigation mechanisms" instead
        of "navigation schemata" for consistency with
        other WAI Guidelines.
template is a commonly used word in English - I don't think it needs
definition. Does somebody who does want to propose a definition?

navigation mechanisms also sounds more consistent with the language that
people actually use (grin)

  5) Under checkpoint 1.4
     a) The second bullet talks about using "title" for
        descriptions of images. This is not recommended by WCAG.
I think this is a wordng issue. How about changing descriptions to associated
     b) Fifth bullet: WYSIWYG is undefined.
Actually it is marked up in accordaance with WCAG. That issue should be
referred to the WCAG group.
  6) Under checkpoint 2.1
     a) (editorial) Text in the first bullet is repeated.
  7) Under checkpoint 2.2
    a) I think the checkpoint should read:
       "Ensure that generated markup conforms to a published
Suits me. Thoughts anyone?
    b) I don't understand the third bullet. It may mean:
       "Use schemas to describe transformations from one
        markup language to another." This may also be done
        with the XSL Transformation language.
Aaah. Another technique for the checkpoint.
  8) Under checkpoint 2.3
    a) I don't understand the example about frames in the
       first bullet. It's not clear whether it means "Don't
       create a frame document with NOFRAMES" or 
       "Don't use a DTD for frames without NOFRAMES".
It means the latter. Should it be reworded, or can someone provide a better
    b) The third bullet should qualify that the statement
       applies to the time of publication of the AU Techniques
We should list the trigger events which we expect to require changes to this
document - change in status of anything to which we refer is such a trigger.
  9) Under checkpoint 3.1
    a) What is the rationale of the second bullet on uppercase letters?
It is a clue for abreviations - we should make that explicit
    b) Fifth bullet: say "natural language"
  10) Under checkpoint 3.2
    a) In first bullet, say "alternative equivalents" instead of
       "alternative information".
    b) In the second bullet, say "image" instead of IMG and refer   
       to a text equivalent instead of alt text.
I agree
  11) Under checkpoint 3.3
    a) The second bullet on clip art long descriptions needs more
I agree.
    b) In third bullet, refer to captions, not "video description files".
Why? The fourth bullet already does that. We can change the order if there is
value in that...
    c) In fifth bullet, there is reference to pre-written descriptions
       that will circulate on the Web. The same was said of shared
       style sheets and I don't think in reality that that is the case.
       I don't have any data to back up that statement, however.
TO the extent that style sheets are circulated (the only ones I know of are
the W3C ones that I find referenced from time to time across the web) it does
seem to do all the things suggested (I have worked with these as a private
contractor for just that reason).
  12) Under checkpoint 3.4
    a) The first bullet is too detailed and difficult to understand
       in its current wording.
I don't think so, although I would be happy to have a simplification, or a
couple of diagrams indicating what was going on.
    b) In the fourth bullet, there is reference to "alternative
       information mechanism" followed by the acronym "ACM". How
       do the two relate? Should it be AIM?
from the first use of the abbreviation:

  "...this alternative information mechansim (ACM) have the..."

But I agree that AIM would seem like a more obvious abbreviation. This
happened because we decided to use the term alternative information instead
of alternative content and I missed making the change in the acronym - it is

Charles McCN
Received on Tuesday, 14 September 1999 18:50:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC