Auto checking of priority 1 checkpoints [was: first step?]

At 11:09 AM 3/13/99 -0800, William Loughborough wrote:
> In other words one of our jobs
>should be to identify any checkpoints that can be objectively validated
>and perhaps even supply a further set of points that explain how to
>subjectively verify compliance.  

Here's the priority 1 checkpoints from 

http://www.w3.org/TR/WD-WAI-PAGEAUTH/full-checklist.html

With first cut at to answer:  Can these be automatically validated for
priority 1 checkpoints? 

The "automatic" assumes we do NOT have natural language understanding
capability in the software.

The answer to whether they can be objectively verified is "yes" unless
otherwise noted.

Arguments are welcome!

>    
> Priority 1 checkpoints
> 
>    In General (Priority 1) 
>    4.1 Ensure that all information conveyed with color is also
>    available without color, for example from context or markup.

No.  But you can warn if text changes color without semantic markup.

>    8.4 For pages that use style sheets or presentation markup,
>    ensure that the contents of each page are ordered and structured.

Partly.  Can verify e.g. nesting of H1 H2 etc.  Cannot verify if blockquote
is for format only.

>    
>    9.1 Until user agents provide the ability to stop the refresh, do
>    not use periodically auto-refreshing pages

yes

>    9.3 Avoid any blinking or updating of the screen that causes
>    flicker.

yes.  Tho you need objective definition of "flicker".  E.g. if just one
character blinks it's not "flicker".  If background turns on and off it is.
 Whats the boundary?

>    6.1 Clearly identify changes in the (natural) language of a
>    document's text.

yes, assuming the change is via tag

>    16.1 Use language that is as simple as possible, while appropriate
>    for the site's content.

no.  I doubt if this can be done objectively either.  Although there are
automated "reading level" indices that could be applied.

>    And if you use images and image maps (Priority 1) 
>    1.1 Provide text equivalents for all images
>    1.3 Provide a text equivalent for each active region of an image
>    map.

not completely.  You can check if there's text, but not if it's really
equivalent.  And the tool can help a human judge.


>    1.6 Replace ASCII art with an image or describe the ASCII art and
>    offer a means (e.g., a link) to skip over it. [Priority 1 or
>    Priority 2 depending on the importance of the information (e.g., an
>    important chart).]

Somewhat.  You can check for strings of common ascii art and blocks made of
non alpha characters.

>    2.1 Provide a long description of each graphic, script, or applet
>    that conveys important information.

Not completely.  You can tell if longdesc exists.  But not if important
info was conveyed. But you can help a human judge

>    And if you use tables (Priority 1) 
>    7.3 For data tables, identify headers for rows and columns.

Partly you can check for column headers, but you don't know if rows should
have headers.

>    7.4 For data tables that have more than one row and/or more than
>    one column of header cells, use markup to associate data cells and
>    header cells.

Yes.  But, is special markup really needed for simple cases?

>    And if you use frames (Priority 1) 
>    8.2 Ensure that descriptions of dynamic content are updated when
>    the dynamic content changes.

To some extent, although you can't tell if the content changed appropriately.

>    14.1 Title each frame so that users can keep track of frames by
>    title.

Partly.  Can verify if there is a title, but not if title is usable to keep
track.  e.g. title="message" better than title="fqz001"

>    And if you use applets and scripts (Priority 1) 
>    1.2 Provide text equivalents for all applets and other
>    programmatic objects.
>    8.3 For scripts that present important information or
>    functionality, provide an alternative, equivalent presentation or
>    mechanism.

Partly. You can verify that something is offered as substitute, but not
that it's equivalent.  Still tool can help judge.


>    And if you use multimedia (Priority 1) 
>    3.1 For stand-alone audio files, provide a text transcript of all
>    words (spoken or sung) and all significant sounds.
>    3.2 For audio associated with video, synchronize the text
>    transcript with the video.
>    3.3 Where sounds are played automatically, provide visual
>    notification and transcripts. [Priority 1 or Priority 2 depending on
>    the importance of the sound.]
>    2.2 For short animations such as "animated gifs," provide a
>    text equivalent and a long description if needed.
>    2.3 For movies, provide auditory descriptions that are
>    synchronized with the original audio.

Partly. Can verify there's something but not if it's equivalent. Still tool
can help judge.




>    And if all else fails (Priority 1) 
>    13.5 If, after best efforts, you can not avoid using a non-W3C
>    technology or any W3C technology in an accessible way, provide a link
>    to an alternative page that uses W3C technologies, is accessible, has
>    equivalent information, and is updated as often as the inaccessible
>    (original) page.

Partly, as usual can verify there's equivalent but not that it's
semantically equivlent, tho you can perhaps give tool to help.

BTY,  why do we insist on w3c technology only in the guidelines?  Isn't it
enough to be accessible?

Len
-------
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 Saturday, 13 March 1999 18:07:21 UTC