- From: Leonard R. Kasday <kasday@acm.org>
- Date: Mon, 26 Jul 1999 17:36:57 -0400
- To: w3c-wai-er-ig@w3.org
Last of the comments
there are just a few comments here
. As before, 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. Especially needed here since my comments are
pretty sparse.
> ------------------------------------------------------------------------
>
>Guideline 7. Ensure user control of time-sensitive content changes
>
>Checkpoint 7.1 - Until user agents allow users to control flickering, avoid
>causing the screen to flicker
>
>Technique 7.1.A [priority 1] Remove any BLINK or MARQUEE elements from
>document
>
> * BLINK and MARQUEE elements should be removed from the document
>
>Language for blink or marquee: BLINK/MARQUEE elements are not defined in
>any W3C HTML specification and should not be used.
>
>Link to test file for this technique.
>
>Technique 7.1.B [priority 1] User notification of potential screen flicker
>
>APPLET, OBJECT, SCRIPT, EMBED and some IMG elements will generate the
>following notification: Display flicker is distracting and may be dangerous
>to some users. Please ensure this element does not cause the display to
>flicker.
>
>IMG elements will generate the notification if they have an HREF to an
>animated GIF image.
>
> ------------------------------------------------------------------------
>
>Checkpoint 7.2 - Until user agents allow users to control blinking, avoid
>causing content to blink
>
>(Handled by technique 7.1.A.)
>
> ------------------------------------------------------------------------
>
>Checkpoint 7.3 - Until user agents allow users to freeze moving content,
>avoid movement in pages
>
>(Handled by technique 7.1.A and technique 7.1.B.)
>
> ------------------------------------------------------------------------
>
>Checkpoint 7.4 - Until user agents provide the ability to stop the refresh,
>do not create periodically auto-refreshing pages
>
>Technique 7.4.A [priority 2] Remove auto-refresh attributes from META
>elements
>
> * If a META element has a HTTP-EQUIV attribute and the value of that
> attribute is "refresh" then check if the element has a 'CONTENT'
> attribute.
> * If the META element has a CONTENT attribute then check if the value of
> that attribute is a URL.
> * If the CONTENT attribute does not have a value of a URL (will contain
> the string "URL=") then it is an auto-refresh page and the HTTP-EQUIV
> and CONTENT attributes should be removed from the META element.
>
>Language for page auto-refresh: This page uses auto-redirect which can make
>the page difficult to read for some people.
>
>Link to test file for this technique.
>
> ------------------------------------------------------------------------
>
>Checkpoint 7.5 - Until user agents provide the ability to stop
>auto-redirect, do not use markup to redirect pages automatically
>
>Technique 7.5.A [priority 2] Remove auto-redirect attributes from META
>elements
>
> * If a META element has a HTTP-EQUIV attribute and the value of that
> attribute is "refresh" then check if the element has a 'CONTENT'
> attribute.
> * If the META element has a CONTENT attribute then check if the value of
> that attribute is a URL.
> * If the CONTENT attribute does have a value of a URL (will contain the
> string "URL=") then it is an auto-redirect page and the HTTP-EQUIV and
> CONTENT attributes should be removed from the META element.
>
>Language for page auto-redirect: This page uses auto-redirect which can
>make the page difficult to read for some people.
>
>Link to test file for this technique.
>
> ------------------------------------------------------------------------
>
>Guideline 8. Ensure direct accessibility of embedded user interfaces
>
>Checkpoint 8.1 - Make programmatic elements such as scripts and applets
>directly accessible or compatible with assistive technologies
>
>Technique 8.1.A [priority 1 if functionality is important and not presented
>elsewhere, otherwise Priority 2] User notification if programmatic elements
>used
>
>OBJECT, APPLET, EMBED, SCRIPT elements will generate the following user
>notification: This element may not be accessible to all users. Please
>ensure there is an accessible interface to this object.
LRK:: important: provide the necessary interfaces to run and test the
direct accessibility.
>
> ------------------------------------------------------------------------
>
>Guideline 9. Design for device-independence
>
>Checkpoint 9.1 - Provide client-side image maps instead of server-side
>image maps except where the regions cannot be defined with an available
>geometric shape
>
>Technique 9.1.A [priority 1] User notification of server-side image map use
>
> * IMG element is a server-side image map if it contains an ISMAP
> attribute.
>
>Language for server-side image map: This image is a server-side image map
>(image name). Use client-side image maps instead of server-side maps.
>
>Link to test file for this technique.
>
> ------------------------------------------------------------------------
>
>Checkpoint 9.2 - Ensure that any element that has its own interface can be
>operated in a device-independent manner
>
>(Image map text links - checked in techniques 1.2.A and 1.5.A.
>
> ------------------------------------------------------------------------
>
>Checkpoint 9.3 - For scripts, specify logical event handlers rather than
>device-dependent event handlers
>
> ------------------------------------------------------------------------
>
>Checkpoint 9.4 - Create a logical tab order through links, form controls,
>and objects
>
> ------------------------------------------------------------------------
>
>Checkpoint 9.5 - Provide keyboard shortcuts to important links
>
> ------------------------------------------------------------------------
>
>Guideline 10. Use interim solutions
>
>Checkpoint 10.1 - Until user agents allow users to turn off spawned
>windows, do not cause pop-ups or other windows to appear and do not change
>the current window without informing the user
>
>Technique 10.1.A [priority 1] Check anchors for 'new window' attributes
>
> * A element opens a new window if it has a TARGET attribute with a value
> of "_blank" or "_new".
>
>Language for anchor that opens new window: This Anchor element (anchor
>text) will open a new window that can be disorienting for some users.
>
>Link to test file for this technique.
>Link to discussion on this technique.
>
> ------------------------------------------------------------------------
>
>Checkpoint 10.2 - Until user agents support explicit associations between
>labels and form controls, for all form controls with implicitly associated
>labels, ensure that the label is properly positioned
LRK:: important: probable error if <TD> is followed by <input> of type
text or textblock.
Also probable error if <input> radio buton s followed by </TD>, <TD>, or
<TR> without intervening text.
LRK:: significant: visually group apparent label. For text labels, it's
the text before it. For checkboxes and radio buttons it's the text after.
>
> ------------------------------------------------------------------------
>
>Checkpoint 10.3 - Until user agents (including assistive technologies)
>render side-by-side text correctly, provide a linear text alternative (on
>the current page or some other) for all tables that lay out text in
>parallel, word-wrapped columns
LRK:: important: this brings to mind a generic sugestion: to display
priority of all checkpoints. This one is a priority 3 for example.
>
> ------------------------------------------------------------------------
>
>Checkpoint 10.4 - Until user agents handle empty controls correctly,
>include default, place-holding characters in edit boxes and text areas
>
> ------------------------------------------------------------------------
>
>Checkpoint 10.5 - Until user agents (including assistive technologies)
>render adjacent links distinctly, include non-link, printable characters
>(surrounded by spaces) between adjacent links
>
> ------------------------------------------------------------------------
>
>Guideline 11. Use W3C technologies and guidelines
>
>Checkpoint 11.1 - Use W3C technologies when they are available and
>appropriate for a task and use the latest versions when supported
>
> ------------------------------------------------------------------------
>
>Checkpoint 11.2 - Avoid deprecated features of W3C technologies
>
>(This looks like something that the editor should check for.)
LRK:: significant: it's also something that the validator will check given
the doctype. So this becomes a requirement on the doctype.
>
> ------------------------------------------------------------------------
>
>Checkpoint 11.3 - Provide information so that users may receive documents
>according to their preferences
>
>(We're doing all we can by prompting user to specify language of document
>in technique 4.3.A.)
>
> ------------------------------------------------------------------------
>
>Checkpoint 11.4 - If, after best efforts, you cannot create an accessible
>page, provide a link to an alternative page that uses W3C technologies, is
>accessible, has equivalent information (or functionality), and is updated
>as often as the inaccessible (original) page
>
>(Should we notify user of this? For every page?)
LRK:: significant: only if problems identified by automatic or manual means
remain. This means that user must have way to manually check off checks
done by hand.l
>
> ------------------------------------------------------------------------
>
>Guideline 12. Provide context and orientation information
>
>Checkpoint 12.1 - Title each frame to facilitate frame identification and
>navigation
>
>Technique 12.1.A [priority 1] Check frames for title
>
> * FRAME element must have a valid TITLE attribute
> * Not allowed - NULL value ("")
> * Not allowed - spaces (" ")
> * Suspicious - placeholder title text
>
>Language for missing frame title: Missing title for this frame (frame file
>name).
>
>Link to test file for this technique.
>
> ------------------------------------------------------------------------
>
>Checkpoint 12.2 - Describe the purpose of frames and how frames relate to
>each other if it is not obvious by frame titles alone
>
>(Suggest that if the frame title does not describe the frame that a
>LONGDESC is needed?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 12.3 - Divide large blocks of information into more manageable
>groups where natural and appropriate
>
>(Any suggestions??)
>
> ------------------------------------------------------------------------
>
>Checkpoint 12.4 - Associate labels explicitly with their controls
>
>(Check for the presence of a validated LABEL element?)
LRK:: minor: sounds good to me.
>
> ------------------------------------------------------------------------
>
>Guideline 13. Provide clear navigation mechanisms
>
>Checkpoint 13.1 - Clearly identify the target of each link
>
>(Search for text string 'click here'? Perhaps display all the anchor text
>and ask user if they are all clear?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.2 - Provide metadata to add semantic information to pages and
>sites
>
>(Suggestions??)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.3 - Provide information about the general layout of a site
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.4 - Use navigation mechanisms in a consistent manner
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.5 - Provide navigation bars to highlight and give access to
>the navigation mechanism
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.6 - Group related links, identify the group (for user
>agents), and, until user agents do so, provide a way to bypass the group
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.7 - If search functions are provided, enable different types
>of searches for different skill levels and preferences
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.8 - Place distinguishing information at the beginning of
>headings, paragraphs, lists, etc
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.9 - Provide information about document collections
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 13.10 - Provide a means to skip over multi-line ASCII art
>
>(Can't be machine checked - this sort of ASCII art is larger than just
>emoticons. User notification?)
LRK:: significant: see note on checking for ASCII art in previous email.
>
> ------------------------------------------------------------------------
>
>Guideline 14. Ensure that documents are clear and simple
>
>Checkpoint 14.1 - Use the clearest and simplest language appropriate for a
>site's content
>
>(Check document using fog index? User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 14.2 - Supplement text with graphic or auditory presentations
>where they will facilitate comprehension of the page
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
>
>Checkpoint 14.3 - Create a style of presentation that is consistent across
>pages
>
>(Can't be machine checked. User notification?)
>
> ------------------------------------------------------------------------
-------
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 17:34:22 UTC