Re: latest version of the document

> http://trace.ie.wisc.edu/wai/19980624txt.htm

> Rating and Classification
> [PRIORITY 3]
>      This guideline should be implemented by an author to make it easier for
>      one or more groups of users to access information in the document.
>      Implementing
>      this guideline is not critical to accessibility, however.
> 

For P3, I'd suggest using "may", not "should", so that it gives us a
clean IETF look-alike must/should/may wording.

>    * For all images (IMG), applets (APPLET),  image map links (AREA), and
>      graphical buttons (INPUT type="image") provide alt-text ("alt")

Shouldn't we be talking about spacer images, bullets and difference
between pure decoration and functional images at that point ? if not
where ?

>    * If OBJECT is used to embed any of the above components, provide text
>      within the OBJECT element.

Also true for APPLET, which have a content much like OBJECT.
(in fact APPLET has both alt and content, so we need to decide which
one to use, and it seems that people have been using content more
often)

> Priority 1
> 3.  Provide textual equivalents of all audio information.  If the audio is
> associated with a visual presentation (movie or animation), synchronize the
> textual equivalents with the visual presentation.
 
> Priority 1
> 4.  Provide textual and auditory descriptions of moving visual information
> (movies, animations, etc.). If the visual presentation is associated with an
> auditory presentation, synchronize the auditory descriptions with the
> existing auditory presentation.

For these two, I'd only make P1 providing textual equivalents for
"important" audio or video information. Same definition as important
for longdesc on image: understanding this piece is necessary for the
overal understanding of the document.

I'n a unix user, with no sound/video whatsoever, and when I get to a
page that is supposed to play a riddle in the background, I just need
to know that it is a riddle, not some operating instructions to access 
more data. If I get a pointer to a audio file for a song, I just want
to know which song I'm missing. If I really want to hear the song, I
can go thru the pain of finding a windows machine around the office
and get to it.


> Priority 1
> 5.  The source of a frame should be an HTML file.
> 
> If other types of information, such as images, are used as the source of a
> frame there is no way to attach alternative information to the information.
> In the image example, there is no way to attach alt-text (.see A-1).

There is both a title and a longdesc on Frame, so one can support
that.

I think it's more important to require a meaningfull title for frame,
ala "index", "navigation bar", etc.
 
> Priority 1
> 6.  Ensure that moving, blinking, or scrolling objects, particularly those
> that contain text, may be paused or frozen.

It's more a UA issue than an author issue.
OK for P2, but not a P1.
 
> Priority 2???
> 7.  Avoid ASCII art and non-letter characters within words.
> 
> Since characteres are used to create a visual image there is no way to
> attach alt-text as with other images (see A-1).   Character spacing and
> non-letter characters cause problems for screen readers.
> 
>   1. For ASCII art, use Style sheets with descriptions or replace art with
>      images with alt-text and descriptions

what is "style sheet with description" ?

There is a way to describe ascii-art online, right after or before the
art itself in html, it's just hard to do it in such a way that it is
visible only for some people and not others, but CSS can help here, as
discussed on the list before.


> Priority 2???
> 8.  Provide visual notification of sounds that are played automatically.
> 
> If a user is accessing the page without sound, information presented through
> sounds played automatically will go unnoticed.
> 
> When the sound is played, display a visual equivalent.

only on demand, again, a UA issue I think.

> Priority 2
> 1.  Separate content and structure from presentation.
> 2.  Use elements and attributes appropriately.

> Priority 1 and 2
> 2.  Enable keyboard operation of all page elements.
> 
> Someone who is using the page without sight, with voice input, or with a
> keyboard (or other input device other than a mouse) will have a difficult
> time navigating a page if keyboard shortcuts are not provided for objects on
> the page.  Access to image maps is impossible for these users if
> alternatives are not provided.

keyboard access can be supported by the UA even if the author hasn't
made any special effort, so this is not a P1.

 
> Priority 1
> 
>   1. For client-side image maps, provide alternative text for links ("alt"
>      on AREA)
>   2. For server-side image maps, provide a list of text links.

That's different, should go into modality, where I think it is
already.

Here I think we should mention that client side image map are better
than server side (there are: even without alt in area, at least you
can get an idea of the choices by looking at the target href, possible 
having the UA fetch the title)

> Priority 2
> 
>   3. Provide keyboard shortcuts to links (including those in client-side
>      image maps), form controls, and groupings of form controls.
>      ("accesskey")
>   4. Create a logical tab order through links and form controls.
>      ("tabindex")

ok, so this is just a issue with the inclusion of alt for maps at this 
point in the document.

> Priority 1
> 1.  For complex frames, describe the layout and purpose of frames and how
> multiple frames and their elements relate to each other.
> 
> Users with blindness and low vision often access the screen with "tunnel
> vision" and are unable to get an overview understanding of the page.
> Complex intertwinings of frames may also be difficult for people with
> cognitive disabilities to use.
> 
>   1. Associate descriptions via d-links with the frame they describe ("rel"
>      or "class" on A).
>   2. Also associate the description directly with the frame ("longdesc")

I don't get the dlink for frame at that point.

I'd say avoid complex frame and use frame title to allow for
serialization of the framing:

  [frame 1: global index]
  [frame 2: top nav bar]
  [frame 3: current page]


> Priority 2
> 2.  Provide titles for images (used as links),  frames, horizontal rules,
> acronyms, and abbreviations.
> 
>    * Titles on images provide information about the destination of the link
>      (whereas the alt-text should provide the basic function of the image,
>      see A-1).
>    * Titles on frames allow user agents (browsers) to create a list of
>      frames so users can keep track of them by name.
>    * Abbreviations and acronyms may be expanded.
>    * Titles can provide information about the purpose of  horizontal rules
>      that may be obvious visually but not auditorally.
> 
>   1. Titles for frames ("title" on FRAME)
>   2. Titles for images ("title" on IMG)
>   3. Titles for abbreviations ("title" on ABBR)
>   4. Titles for acronyms ("title" on ACRONYM)
>   5. Titles for horizontal rules ("title" on HR)

ok, so frame is covered, my comment applies to avoiding complex frames.

> Priority 2
> 5.  For complex tables, provide summaries, associate cells with row and
> column headers, and group cells into categories.
> 
>    * Tables summaries provide an overview of the table and are useful by
>      people who are unable to see the whole table.
>    * Similarly, associating cells explicitly with their row and column
>      headers allows a user to view the table cell by cell.
>    * Grouping cells into categories will allow future user agents to create
>      various views of the table.
> 
> These guidelines benefit users that are accesing the table auditorally or
> viewing only a portion of the page at a time (users with blindness and  low
> vision, or using an auto-pc, or devices with small displays)
> 
>   1. Summaries for tables ("summary" on TABLE)
>   2. Associate cells with row and column headers ("headers," and "scope" on
>      TD)
>   3. Group cells into categories ("axis" on TD)


We need to define what is complex for frame and table. For frame I
suggest more than 3, for table, we start discussing it in  
http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JanMar/0213.html


> Priority 2
> 2.  Use elements and attributes that comply with a W3C HTML, CSS, or XML
> specification.
> 
> By avoiding proprietary elements and complying with a W3C specification you
> increase the likelihood that your page will be more consistent across
> platforms as well as more usable by a variety of populations.
> 
>   1. HTML 2.0, 3.2, 4.0
>   2. CSS-1 or -2
>   3. XML 1.0

To me, this is a P1. I'd even go as far as saying that until we've
better defined what constitute accessible XML, we should restrict
ourselves to HTML and CSS.

This is a P1 because if you don't know the format (be it an extension
to HTML/CSS, or a completetly new format), there is nothing a
user-agent can do to adapt to the user preferred modality.

Received on Monday, 29 June 1998 08:16:00 UTC