Techniques document: more comments on checkpoints 1.x

Here's some comments on the techniques document that chris is editing. I've
labeled comments as "minor: signficicant", "important"

This has most text of original.  I've preceded my comments with LRK:: so
you can quickly skip to them.

This is for checkpoints 1.x, i.e. 1.1, 1.2 ...


-----------


> It also describes methods for modifying HTML
>documents so that they will conform to these guidelines.

LRK:: minor: for the software to modify...


>creation of software programs (A-Prompt, Bobby) and we want the software to

LRK:: minor: add "e.g." before A-prompt...


>Guideline 1. Provide equivalent alternatives to auditory and visual
>content.
>
>Checkpoint 1.1 - Provide a text equivalent for every non-text element.
>
>Technique 1.1.A [priority 1] Check Images for ALT text
>
>   * IMG element must have a valid ALT attribute.
>
>Valid ALT text:
>
>   * Not allowed - NULL ALT value (ALT="")
>   * Allowed - ALT value of 1 or more spaces (ALT=" ")

LRK:: important: we're awaiting word from GL on null and blank alt text.
See discussion at 

http://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Jun/0050.html

especially part about null or blank alt text for links.  Please fold in
"suggestions" we made to GL pending their approval.


>   * Suspicious - ALT attribute value could be file size (ends with
>     "bytes")
>   * Suspicious - ALT attribute value ends with image file suffix.
>   * Suspicious - ALT attribute value is placeholder ALT text.

LRK:: important: define placeholder, i.e. text supplied by generally used
or available HTML editors.

LRK:: important: in all cases, even if ALT text passes tests, show picture
and ALT text so that user can verify that ALT text is suitable.

>Language for missing ALT text: Missing ALT text for image
>Language for suspicious ALT text: Suspicious ALT text for image

LRK:: significant:  label as "suggested" language.  We don't want to limit
designers here.  For example, they may want to use icons (with appropriate
ALT text of course)

>
>Suggestions for possible ALT text:

LRK:: minor: reword: "Ways that program can automatically suggest alt text"

>  1. If the document contains another instance of the image and that image
>     contains ALT text, suggest that ALT text.

LRK:: significant: if the _site_ contains another instance...

>  2. If the width of the image and the height of the image are both less
>     than 20 pixels, suggested text should be "bullet".
>  3. If the height of the image is less than 20 pixels and the width of the
>     image is greater than 150 pixels, suggested text should be "horizontal
>     rule".
>  4. Other suggestions by Daniel Dardailler
>  5. Suggestions by Michael Vorburger

LRK:: signficant:  give url's of Daniels and Michael's documents or better
yet, add to list..

>Other checks:

>  1. After user has entered ALT text for the image, check the document for

LRK:: signficant: check the _site_ , not just the document ...

>     other instances of the image. If the document contains other images
>     that are the same and they do not have ALT text, suggest that all same
>     images without ALT text use the new ALT text.
>
>Link to test files for this technique.
>
>Technique 1.1.B [priority 1] Check images for LONGDESC
>
>   * IMG element should have a valid LONGDESC attribute if the image is
>     complex.
>   * If IMG element has no LONGDESC attribute and could be a complex image,
>     ask user if the image is complex and requires a long description.

LRK:: signficant:  I suggest that this be folded in with display of images
and ALT text.  Display description pointed to by LONGDESC, or alert user at
that time if no LONGDESC.  This eliminates need to evaluate what's a
"complex" image or the bullet and   rule line below.

>Images that do not require a LONGDESC:
>
>   * bullets - width and height of image are both less than 20 pixels
>   * horizontal rules - height of image is less than 20 pixels and width of
>     image is greater than 100 pixels
>
>Valid LONGDESC URI:
>
>   * Any valid URI
>
>Language for missing LONGDESC: Complex images require a long description.

LRK:: significant:  this is global comment.  In general, label all
"language" as "suggested language".

>
>Link to discussion on this technique.
>Link to test files for this technique.
>
>Technique 1.1.C [priority 1] Check input buttons that use an image for ALT
>text
>
>   * If an INPUTelement has a TYPE attribute with a value of "image" then
>     the INPUT element must also have a valid ALT attribute.
>
>Valid ALT text:
>
>   * Not allowed - NULL ALT value (ALT="")
>   * Allowed - ALT value of 1 or more spaces (ALT=" ")


LRK:: important: ALT=" " not allowed for button.  It's important to give
function of button.

>   * Suspicious - ALT attribute value could be file size (ends with
>     "bytes")
>   * Suspicious - ALT attribute value ends with image file suffix.
>   * Suspicious - ALT attribute value is placeholder ALT text.

LRK:: significant:  see above comment for placeholdere ALT text.
LRK:: minor: instead of repeating these rules, put all in one place and
refer to them to avoid possible errors in future. Except of course for the
case of ALT="" or ALT=" " which is not allowed for buttons but is for
non-link text.

>
>Language for missing ALT text: Missing image for this input element.
>
>Language for suspicious ALT text: Suspicious ALT text: (current ALT text)
>
>Link to test files for this technique.
>
>Technique 1.1.D [priority 1] Check applets for ALT text
>
>   * APPLET element must have a valid ALT attribute.
>
>Valid ALT attribute text:
>
>   * Not allowed - NULL ALT value (ALT="")
>   * Allowed - ALT value of 1 or more spaces (ALT=" ")

LRK:: important: again, see above discussion of null and blank alt text.

>   * Suspicious - ALT attribute value could be file size (ends with
>     "bytes")
>   * Suspicious - ALT attribute value ends with image file suffix.
>   * Suspicious - ALT attribute value is placeholder ALT text.
>
>Language for missing ALT text: Missing ALT text for applet.
>
>Language for suspicious ALT text: Suspicious ALT text: (current ALT text)
>
>Link to test files for this technique.
>
>Technique 1.1.E [priority 1] Check Applets for alternative content
>
>   * Between the APPLET start element and APPLET end element must be a
>     valid text element.
>
>Valid text element:
>
>   * Must contain at least one word of text
>   * Suspicious - ALT attribute value is placeholder ALT text.
>
>Language for missing alternative content: Missing alternative content for
>applet.
>
>Language for suspicious alternative content: Suspicious alternative
>content: (suspicious text)
>
>Link to test files for this technique.


LRK:: important: provide quick means for user to view applet and
alternative content, preferably side by side, to check for equivalence.
This also applies to OBJECT.

LRK:: important: provide means to check if applet itself is accesible.  Do
we need to check both Microsoft and Sun/IBM methods of access?


>Technique 1.1.F [priority 1] Check objects for alternative representation
>
>   * Between the OBJECT start element and OBJECT end element must be a
>     valid text element.


LRK:: important.  No.  Alternative can be another object. For example, an
image with ALT text.


>Valid text element:
>
>   * Must contain at least one word of text.
>   * Suspicious - ALT attribute value is placeholder OBJECT ALT text
>
>Language for missing alternative representation: Missing alternative
>representation for this object.
>
>Language for suspicious alternative representation: Suspicious alternative
>representation: "suspicious text"
>
>Link to test files for this technique.
>
>Technique 1.1.G [priority 1] Check frames for an associated LONGDESC file

LRK:: significant: see LONGDESC comments made above.


>   * FRAME elements should have a valid LONGDESC attribute if the frame
>     title does not completely describe the frame content
>   * If FRAME does not have a LONGDESC attribute, ask user if frame
>     contents are complex and requires one.
>
>Valid LONGDESC file name:
>
>   * Must not be NULL
>   * Must be a valid URI
>
>Language for missing LONGDESC: Missing 'long description' file for this
>frame.
>
>Language for suspicious LONGDESC: Suspicious 'long description' file name:
>"file name"
>
>Link to discussion on this technique.
>Link to test files for this technique.
>
>Technique 1.1.H [priority 1] Check AREA elements for ALT text
>
>   * AREA elements must have a valid ALT attribute.
>
>Valid ALT attribute:
>
>   * Not allowed - NULL ALT value (ALT="")
>   * Suspicious - ALT attribute value is placeholder ALT text.

LRK:: important: blank value ALT=" " not allowed either.
LRK:: signficant: carry over rest of ALT text discussion or better yet
point to it.


>Language for missing ALT text: Missing ALT text for this image map area.
>
>Language for suspicious LONGDESC: Suspicious ALT text for this image map
>area: (ALT text).
>
>Link to test files for this technique.
>
>Technique 1.1.I [priority 1] Check if audio files have an associated text
>transcript
>
>   * If the target of an A element is a sound file then ask the user if
>     there is an existing text transcript file.
>
>Language for suspected missing text file: Audio files require an associated
>text transcript file. Is there an associated text file for this audio file
>(audio file name)?
>
>Link to test files for this technique.
>
>Technique 1.1.J [priority 1] Check SCRIPT element for associated NOSCRIPT
>element
>
>   * There must be a NOSCRIPT element immediately following a SCRIPT end
>     element.
>   * The NOSCRIPT start and end elements must contain at least one valid
>     text element.
>
>Valid text element:
>
>   * Must contain at least one word of text
>   * Suspicious - ALT attribute value is placeholder NOSCRIPT text.
>
>Language for missing NOSCRIPT: Missing NOSCRIPT element for this SCRIPT
>element.
>
>Link to test files for this technique.


LRK:: important: allow user to compare script and noscript alternatives,
preferably side by side.


>Technique 1.1.K [priority 3] User notification for ASCII art
>
>This technique describes notifications presented to the user for
>checkpoints that can not be machine tested.
>
>BODY elements will generate the following user notification: If there is
>any ASCII art in this document, please give it a textual description.
>
>Link to discussion on this technique.
>Link to test files for this technique.

LRK:: signficant: algorithm for spotting ASCII art, e.g. series of n or
more punctuation characters or clusters of repeated letters...
>
>  ------------------------------------------------------------------------
>
>Checkpoint 1.2 - Provide redundant text links for each active region of a
>server-side image map.
>
>Technique 1.2.A [priority 1] Prompt user for text links if ISMAP used.
>
>   * If an IMG element has a valid ISMAP attribute, prompt the user for
>     associated text links.

LRK:: important: let user select purported equivalent links and check
against server links.  The server side links may be obtained by having user
click on each apparently selectable region; or generated automatically by
sending grid of selection points to server (as done by some robots).


>Valid ISMAP attribute:
>
>   * Must be a valid URL
>
>Language for prompt: Server-side image maps should have associated text
>links. Are there text links in your document for this image map (image map
>file name)?
>
>Link to test files for this technique.
>
>  ------------------------------------------------------------------------
>
>Checkpoint 1.3 - Until user agents can automatically read aloud the text
>equivalent of a visual track, provide an auditory description of the
>important information of the visual track of a multimedia presentation.
>
>(Can't be machine checked. User notification if movie file found?)

LRK:: important: allow user to run track and listen to description.  This
also applies to checkpoint 1.5.

>  ------------------------------------------------------------------------
>
>Checkpoint 1.4 - For any time-based multimedia presentation (e.g., a movie
>or animation), synchronize equivalent alternatives (e.g., captions or
>auditory descriptions of the visual track) with the presentation.
>
>(Can't be machine checked. User notification?)
>
>  ------------------------------------------------------------------------
>
>Checkpoint 1.5 - Until user agents render text equivalents for client-side
>image map links, provide redundant text links for each active region of a
>client-side image map
>
>Technique 1.5.A [priority 3] Prompt user for text links if USEMAP used.
>
>   * If an IMG element has a valid USEMAP attribute, prompt the user for
>     associated text links if the document does not already contain
>     associated text links.
>   * Associated text links may be found by searching the document for
>     anchors with HREF values that correspond to the AREA elements in the
>     given USEMAP.
>
>Valid USEMAP attribute:
>
>   * Must be a valid URL
>
>Language for prompt: Client-side image maps should have associated text
>links.
>
>Link to test files for this technique.

LRK:: important: have use specify purported text links.  Program then
checks against links in the image maps
>

-------
Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org        
(215} 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Monday, 26 July 1999 16:20:42 UTC