W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 1997

Comments on Trace Version 8

From: Daniel Dardailler <danield@w3.org>
Date: Fri, 07 Nov 1997 15:31:49 +0100
Message-Id: <199711071431.PAA08215@www47.inria.fr>
To: w3c-wai-gl@w3.org
 
General comments (maybe I should rate them with stars too :-)

 - I think the TOC at the beginning should point only to local anchors
   in the document, rather then a mix of both internals and externals
   (like quick guides). The pointers to external document should be
   gathered in the format section.

 - furthermore, I think the section 
      Profiles of users with disabilities
   and many others sections (tutorials, etc, see comments below) should
   on in separate documents.

 - I don't like the word TOMORROW, as it has a connotation "to be
   done in the future, shouldn't care today", where in fact, people
   should start changing their markup today with the result taking effect
   in the future (much like seeding)
 
   I also prefer CURRENT over TODAY, but not as strongly.
 
   I'd like to have a keyword for CURRENT+NEW: ALWAYS.
 
   So I'd prefer
      CURRENT
      NEW
      ALWAYS

 - it would be better if not only the recommendations, but also the
   example, the tips and the intro to the issues, where rated as TODAY
   or NEW or ALWAYS.

 -  Recommendations for user agent (browser) designers
    Recommendations for assistive technology designers
    Suggestions for users
 
   Throughout the document, there are sections for browser and tools and
   users. I strongly think this should go in their own book. I agree
   there are relationship between the different guidelines, but since
   the audience is different, I don't see why they should be
   bundled. Our primary focus should be to make each document very
   simple to comprehend.
   The goal is also to make each guideline document easier to manage.
   I have only reviewed the page author part.

 - At some point, we need to go over the WAI archives (IG/HC) and
   gather all the cases where we mentioned "this should be in the
   Markup guidelines, not in the HTML format itself"

 - I'd like to have the quick and check list in some sort of
   prioritized order, not just the header of the guideline doc. Some
   kind of top 5 and then the rest.


Onto the documents itself (my comments start on column 1)


 Screen Reader
     A software program that runs on a computer and reads the contents
     of the screen aloud to a user. Used primarily by individuals who
     are blind. Can only read text that is printed, not painted, to the
     screen.

I think we should try to explain better somewhere and make the
difference here between screen readers that are Markup aware and those
who operates on a formatted output.


                    5. [Place holder for "HTML and URLs"]

             6. [Place holder for "HTML Document Character Set"]

                7. [Place holder for "Basic HTML data types"]

                 8. The global structure of an HTML document

                       The HEAD and BODY of a document



I think an HTML tutorial as a separate document (or in the annex) is a
better idea.


     [2 star.] Use the TITLE element in the HEAD of each document.
     [TODAY & TOMORROW]
     For example, <HTML><HEAD>...<TITLE>Version 8 of the Unified Web
     Accessibility Guidelines</TITLE>...</HEAD>...

This is mandatody since HTML3.2. Every HEAD must have a TITLE.

But I guess the more relevant question, rather that saying it's not
valid if not there, is to look on the web today for the existing use
of TITLE. If a large manjority of HTML authors are already using it,
then we shouldn't mention it here (again, to save bandwidth).


     [2 star.] Use the full text of dates. [TODAY & TOMORROW]
     For example, February 28, 1996.  Even if the user speaks a
     different language, the date can be easily interpreted.

I think this is in the range: make sense, use good design. I'm not
sure we want to point at all the issues of that kind. I understand the
problem is always worse for accessibility, so I think it's a matter of
priority, i.e. how much worse is the issue. This one, I think is low.



  1. [3 star.]- Use style sheets: [TOMORROW]

Related to my wanting NEW instead of TOMORROW, this is the kind of
thing I'm worry about: Use Style sheet tomorrow (not today :-)

CSS is in IE since August 96 and in NS 4 this year.

It's not tomorrow.

  2. [3 star.] - Use proportional and logical styles rather than physical
     markups [TODAY & TOMORROW]
     Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1, H2, etc.
     Proportional: size=+1 or size=-4

The HTML FONT tag is deprecated altogether in HTML 4 so we should just
point at CSS rather than saying proportional size is good (even if
it's better than physical, which I agree).
 


 10.3 Punctuation, symbols and ASCII art

     Issue:  Screen reading software often ignores or reads each name
     for punctuation that has been used to make an emoticon or ASCII
     art.  For example, the smiley emoticon :-) would either be ignored
     or read as "colon dash close parentheses."

"colon dash close parentheses" 
That's the way I parse it myself :-)


     [2 star.] Use a graphic with alt-text to avoid uncommon
     typographic characters or constructions such as emoticons, arrows
     consisting of dashes and greater than signs -->, etc.. [TODAY &
     TOMORROW]

I think the point about emoticons is only CURRENT and in the NEW
agents, there should be enough intelligence to recognize a predefined
list of smileys.

 
  1. [3 star.] Use the appropriate list markup for lists and list items.
     [TODAY & TOMORROW]
  2. This is an ongoing topic of discussion, stay tuned for developments.

I mentioned that on the list: CSS with img in CSS or img in HTML
depending on the semantics conveyed by the img.


  12.1 Comprehension and navigation of table elements

     Issue 1:  Newspaper columns. Tables are often used to layout pages
     of text in newspaper columns.  Screen Readers read all the way
     across the page reading sentences on the same row from different
     columns as one sentence.

In the intro sections, like here, I would like to see mentioned that
"dumb" screen reader operates like that, not markup aware products.


  1. [3 star.] Avoid using tables to arrange text documents in columns or
     otherwise layout a page. Instead use style sheets. [TOMORROW]

This is called positioning and it's in CSS2.

 Testing tips

  1. To predict how a screen reader might read your table, hold a piece of
     paper up to your monitor and read completely across the screen. As you
     slide the paper down the monitor, read aloud to another person the text
     that appears above the line the paper creates (without pausing for
     gaps). Does what they hear make sense?

This is clearly a TODAY example.

  2. Another method to predict how a screen reader will interpret your page
     is to save it as text only (available in the "File" menu in most
     browsers) then open it with a word processing program.

That's strongly dependant on the tool being used.

Maybe we should point to a "lynxer" service and use that as our
acceptance criteria for linearization of HTML.


     [3 star.] Include enough words in the link phrase that it will
     make sense when read out of context. [TODAY & TOMORROW]
     A person should be able to read a list of just the links from a
     page and be able to select one without finding what context it was
     used in. For example: "click here, click here, click here" would
     not allow a person to select a link without reading the context.
     Something more meaningful would be: "download the full version of
     this document in ASCII text, download the full version zipped with
     gzip, view the full version in HTML."


On link, using TITLE on A should be a NEW way of conveying the
semantics of the link, as an alternative of people really wanting to
use "Click here" as the link text.

 
  13.4 Methods for linking to alternate pages

 
I have an overall issue about text alternate page, that I will bring
up here, but it applies to most mention of providing a text-only
version.

In short: it's a possible CURRENT practice but we shouldn't promote it
for the future, rather we should promote one single source and
multiple SS.


 Recommendations for page authors

  1. [4 star.]Include alt-text for all images and image maps.  [TODAY &
     TOMORROW]
     All images should have alt-text that describes the function of the
     graphic. Examples: "XYZ Logo," "Section Title: Banana Products," "Graph
     of population versus age," or "Search Button." 

One important message is that if ALT on IMG is **** then ALT on IMG
that are in A is ******.

Also I don't see the guideline for ALT text for decoration elements
(should it be ALT="" or ALT="red flower" ?)


    The alt attribute is mandatory for the AREA and IMG elements,  but
    should also be used for APPLET, and INPUT. 

ALT for APPLET is TODAY while content for OBJECT is NEW.

  2. [4 star.] Use the title attribute of the A element to provide more
     information about the image/link for links to images where alt-text is
     not possible (when an image is linked to from a frame). [TODAY &
     TOMORROW]
     For example: <A href="http://www.server.com/images/pic3.gif" title="Two
     photos of the happy couple from their earlier years.">Elementary</A>

We need to be more detailed on the relationship TITLE/ALT in the A/IMG
context (related to the recent TOOLTIP discussion on the list).


  3. [4 star.]Provide a link to a longer description. (This is especially
     critical information in charts, tables, and diagrams.) [TODAY &
     TOMORROW]

D-link is CURRENT, LONGDESC is NEW, so we need two entries here.

  5. [4 star.] Use client-side instead of server-side image maps [TODAY &
     TOMORROW]

Image map should be refined using
  - ALWAYS: use client side
  - CURRENT: provide ALT for AREA (when using MAP)
  - CURRENT: provide text right after server side if no other option
  - NEW: use OBJECT integrated desc+A

 
      1. Use the alt attribute of the AREA tag (with the IMAGE, MAP and
          AREA tags)
          <IMG src="welcome.gif" alt="Image map of areas in the library"
          usemap="#map1">
          <MAP name="map1">
          <AREA coords="0,0,30,30" href="reference.html" alt="Reference">
          <AREA coords="34,34,100,100" href="media.html" alt="Audio Visual
          lab">
          </MAP>
       2. Use the alt attribute of the AREA tag (with the OBJECT, MAP and
          AREA tags)
          <OBJECT data="welcome.gif" usemap="#map1">
          alt="Image map of areas in the library" </OBJECT>
          <MAP name="map1">
          <AREA coords="0,0,30,30" href="reference.html" alt="Reference">
          <AREA coords="34,34,100,100" href="media.html" alt="Audio Visual
          lab">
          </MAP>
       3. Use the title attribute of the A tag (with the OBJECT and SHAPES
          tags)
          <OBJECT data="welcome.gif" shapes>
          Areas in the library
          <A coord="0,0,30,30" href="reference.html" title="Reference">
          <A coords="34,34,100,100" href="media.html" title="Audio Visual
          lab">
          </OBJECT>


Maybe this should go into a tips section, to make the recommendation
itself short.

 
  3. [4 star.] HOWEVER, do not require the use of style sheets.  If your
     page is unusable when style sheets are turned off, provide an alternate
     page which doesn't use them.

We should recommend that this should never be the case.

  1. [4 star.] Provide a NOFRAME option [TODAY & TOMORROW]

Once the screen reader can intelligently parse FRAME, NOFRAME will not
be an issue anymore, so this is TODAY only.

 
        20. [Place holder for "SGML reference information for HTML"]
                  21. [Place holder for "SGML Declaration"]
              22. [Place holder for "Document Type Definition']
       23. [Place holder for "Transitional Document Type Definition']
         24. [Place holder for "Frameset Document Type Definition"]
              25. [Place holder for "Named character entities"]

Better in a separate document I think.

 
Received on Friday, 7 November 1997 09:32:09 GMT

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