W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 1998

Review of WD-WAI-HAG-19980123

From: Daniel Dardailler <danield@w3.org>
Date: Mon, 26 Jan 1998 15:28:17 +0100
Message-Id: <199801261428.PAA11238@www47.inria.fr>
To: w3c-wai-gl@w3.org

[my comments are organized as a list where each item starts with a DD:
on column 1 followed by the section number or name]

DD: "Status of this document" section.
 unfinished sentence:
   The goal of the WAI-GL group is to ...
 I think it should point to the charter.


DD: "Comments" section.
 I don't like the sentence that says:
 "We cannot guarantee a personal response but we will try when it is
 appropriate."

 Basically, this means: we can ignore your comment/request if we want,
 and that's not acceptable.
 We need to point people to an up-to-date "issue list" document where
 *all* the issues raised are stored together with their status (need
  more discussion, ok to be incorporated, no for this and this
  reason, etc) and their origination (author, date, pointer to
  message/thread).

I have several requests for Rating change:

DD: 2.5 Provide descriptive titles for all images used as links.
  From Recommended to Required

DD: 8.1 Create link phrases that make sense when read out of context.
  From Recommended to Required
  Even though this is something the browser could have a say about,
  and help with, I think we should make it a required as it is really
  a very important navigability issue

DD: 5.1,2,3 
  HTML structural elements are only used to convey meaning, not presentation. 
  HTML presentational elements are only used to convey presentation,
  not meaning.  
  Headings are nested properly and are not used for layout. 
  All 3 From Recommended to Required, they need to  be at the same
  level as using SS at the beginning.

DD: 6.1 List structure and list items are correctly encoded.
  From Recommended to Required - same thing as above.

DD: 3.
  In the Applet section, I think there is too much Required.
  Given that Java Accessibility is going to be a reality, we should
  force people to transcribe their applet in some other formats.

DD: 9.1 Ensure that your pages are readable and usable without frames.
  From Required to Recommended, or an Interim.
  A browser issue really. 

More comments:

DD: 2.5
  We should also add "descriptive link title", or "description anchor
  title" to disambiguate with the IMG title.(the example is clear,
  but it's dropped from the checklist for instance)

DD: 2.1
  We need a section focus on ALT/TITLE/A-TITLE/LONGDESC usage
  (I sent a separated message about it already)

DD: 3. Applets and Scripts
  Say upfront that APPLET is deprecated.

DD: 4.
  Need more examples for AUDIO/VIDEO.
  I understand this could go in the Central Reference but as is, it is
  inconsistent with other section, such as image, form, which are full
  of example. Either they all get examples, or none of them do. I'm
  for putting at least a short example in all sections (It's nice that
  they are all marked with a class=example, and <CODE>)

  For the TABLE example appendix, I'd move it to the Central Ref and
  keep a shorter version inline (no appendix here in other words, besides
  the checklist)


DD: 6.
  We need to talk about list that use image as bullet here, as it is
  one of the most recurrent abuse of HTML structuring.
  I'm reposting my examples:
 
  First, the image is purely decorative and can be expressed solely in
  CSS.
 
  UL { list-style: url(button.png) }
  <UL>
  <LI> Audrey
  <LI> Laurie
  <LI> Alice
  </UL>
 
  Second, the image conveys some information and has to appear in the
  markup, not in the style (and the default style list visual is turned
  off so that you don't get double bullet) 
 
  UL { list-style: none }
  <UL>
  <LI> <IMG SRC=browneye.png ALT="bullet. brown eye drawing"> Audrey
  <LI> <IMG SRC=greeneye.png ALT="bullet. green eye drawing">Laurie
  <LI> <IMG SRC=blueeye.png ALT="bullet. blue eye drawing">Alice
  </UL>

DD: 12. 3.
  Offer navigation bars for easy access to the navigation structure. 

  Apparently, pages that starts with a navbar are bad for sequential
  reading (speech in particular) as they force the listener to listen
  to the same navbar over and over again.
  I think we need to be a little more specific and I suggest we
  propose a authoring guidelines to "classify" navbar, using the HTML
  class attribute applied to the element used (frame, image map) or a
  DIV if there is no navbar element per se:

  <div class=navbar>
  <A HREF=foo>Search</A> | <A HREF=bar> Home </A>
  </div>
 
  This way a browser can move it down the page or offer it as an
  option on demand.

DD: 12.12 
  Test the site with at least:
        a text only browser (such as Lynx) 
        a self-voicing browser (such as PWWebspeak) 
  I think requiring lynx is OK (given web ready lynx-it service) but
  self voicing is unrealistic.
Received on Monday, 26 January 1998 09:28:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:46:57 GMT