Re: Techniques document: more comments on checkpoints 1.x

Len,

Thanks for your helpful comments. I've put most of them into the document
and will have the new version posted at the A-Prompt site tomorrow Fri. Aug.
6 (http://aprompt.snow.utoronto.ca/docs/Implementation.html).

I have a few comments on your suggestions:

> > It also describes methods for modifying HTML
> >documents so that they will conform to these guidelines.
>
> LRK:: minor: for the software to modify...
>
CR:: I don't understand this. Are you suggesting "It also describes methods
for the software to modify documents so that they will conform to these
guidelines."?


> 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.
>
CR:: We are designing a 'review' or 'verify' mode so that the user can
review/verify what is actually in the document. I think this is what you're
suggesting. We really don't want to present the user with items that are OK
when they are in 'evaluate/repair' mode and only questionable items should
be shown. When we get the 'review' mode working it will address some of your
following comments.


> >Suggestions for possible ALT text:
>
> LRK:: minor: reword: "Ways that program can automatically suggest alt
text"
>
CR:: Daniel has made a suggestion that we use the more generic 'repair
technique' text for these sort of suggestions. OK?


> >   * 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.
>
CR:: For the 'review/verify' mode this makes sense. For 'evaluate/repair'
mode I think we'll have to ask the user for every image (that's not a bullet
or HR) whether it's complex and requires a LONGDESC.


> >Technique 1.1.K [priority 3] User notification for ASCII art
> >
> LRK:: signficant: algorithm for spotting ASCII art, e.g. series of n or
> more punctuation characters or clusters of repeated letters...
>
CR:: Developing the algorithm will take a lot of work. Anybody got some free
time?


> >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).
>
CR:: Good idea. I've heard that some servers can provide a set of links and
associated coordinates for the image map if you ask for it.


> >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.
>
CR:: This is a good idea. We would like to add a media player to A-Prompt
for doing just this sort of thing. It likely won't get into this version
though.

Chris


----- Original Message -----
From: Leonard R. Kasday <kasday@acm.org>
To: <w3c-wai-er-ig@w3.org>
Sent: Monday, July 26, 1999 4:23 PM
Subject: 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 Thursday, 5 August 1999 16:28:41 UTC