- From: Wendy A Chisholm <wendy@w3.org>
- Date: Fri, 04 Feb 2000 18:00:56 -0500
- To: "Leonard R. Kasday" <kasday@acm.org>, w3c-wai-er-ig@w3.org
my comments are prefixed with WC::
>| Evaluation:
>| The HTML element(s) that must be examined
>LRK:: Add ", and algorithms and heuristics used to examine them"
WC:: done.
>| Example Language:
>| Messages displayed to the author if a problem is found
>LRK:: Change to "Example of a message displayed.
WC:: changed to, "Example of a message to be displayed"
>| Repair Techniques:
>| Methods for repairing the HTML code
>| Test Files:
>| Used to test evaluation tools to see if they find the accessibility
>| problem
>| Discussion Files:
>| Discussion and comments on the technique
>
>LRK:: Add "Note that this document specifies only the function of
>evaluation of repair tools. Nothing in this document should be taken to
>imply a particular user interface."
WC:: added, "Note. This document specifies only the function of evaluation
and repair tools. Nothing in this document should be taken to imply a
particular user interface."
>LRK:: This is a cross group issue. We need a way for an author to
>indicate that a warning has been checked. E.g. after the author has
>asserted that no LONGDESC is needed for an image, the warning shouldn't
>pop up with every subsequent use of the tool when that image is
>encountered. This could be done, for example, with special comments
>inserted in the html, analogous to the comments which turn off warning
>messages when a C program is run through Lint.
WC:: created an open issue. was discussed a bit at the 31 jan 2000 telecon.
>|
>| Images that do not require a LONGDESC or descriptive link:
>|
>| * bullets
>LRK:: Add "See Appendix J"
>
>| * horizontal rules
>LRK:: Add "See Appendix K"
WC:: done.
> ==================
>| Technique 1.1.C [priority 1] Check input buttons that use an image for ALT
>
>|
>| * If an INPUTelement has a TYPE attribute with a value of "image" then
>TYPO:
WC:: done
> ^
>
>| it must also have a valid ALT attribute.
>
>LRK:: This mostly is same as 1.1.A. Instead of repeating it, just point
>there and describe any differences (the only difference I can think of is
>that the acceptability of null text when there is text next to image
>inside anchor doesn't apply, i.e. <A ...> <IMG ALT=""> some text </A>
>which should be OK in 1.1.A doesn't apply here. Other rules are same.
WC:: group resolved to leave as is on 31 january meeting.
>| Technique 1.1.D [priority 1] Check applets for ALT text
>|
>| * APPLET element must have a valid ALT attribute.
>LRK:: Is this needed if the user, in accordance with 1.1.E, has code
>before </applet> that shows up when
>user agent skips applets?
WC:: yes.
>|
>| Valid ALT attribute text:
>LRK:: replace list with reference to 1.1.A
WC:: is not the same.
> ==================
>| Technique 1.1.E [priority 1] Check Applets for alternative content
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Between the APPLET start element and APPLET end element must be a
>| valid text element or a valid link to a URI.
>LRK:: Replace with "Any HTML". However, tool must then (recursively)
>apply all tests to that HTML.
WC:: open issue.
> ==================
>| Technique 1.1.F [priority 1] Check objects for alternative representation
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Between the OBJECT start element and OBJECT end element must be a
>| valid alternative representation element.
>|
>| Valid alternative representation element:
>LRK:: Same comment as for applets. Alternative content can be any HTML,
>but all technique tests must recursively be applied.
WC:: open issue.
> ==================
>| Technique 1.1.G [priority 1] Check frames for an associated LONGDESC file
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * FRAME elements should have a valid LONGDESC attribute if the frame
>| title does not completely describe the frame content.
>LRK:: We can't automatically check if title "completely
>describes...". This warning must always be offered. See issue above
>about turning off the warning when the author has fixed it.
WC:: we discussed this at the 31 january meeting. I propose rewording it as
follows:
<blockquote>
Evaluation:FRAME elements should have a valid "longdesc" attribute if the
value of the FRAME "title" attribute does not completely describe the
frame content.
Refer to techniques for checkpoint 12.1
If a FRAMESET has three or more frames and does not have a "longdesc"
attribute, ask the user if the relationships between frames are not
apparent in the titles for each frame.
Valid "longdesc" file name:
Must not be NULL
Must be a valid URI
Example of a message to be displayed:
Missing "longdesc": Missing 'long description' file for this frame.
Invalid "longdesc" file name: Invalid 'long description' file name for this
frame: [current "longdesc" file name] - [can not be empty].
Repair Technique:
If the relationships betweeen frames are not obvious then ask that they
provide a description of the relationships. Allow the user to create a
"longdesc" file or associate an existing "longdesc" file. It is suggested
that each FRAME in the FRAMESET reference the same "londesc" as the
description of the relationships should be available from each FRAME.
</blockquote>
>| * 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
>LRK:: The tool should then check the file that is pointed to.
>|
WC:: check it for what?
>
>
> ==================
>| Technique 1.1.H [priority 1] Check AREA elements for ALT text
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * AREA elements must have a valid ALT attribute.
>LRK:: refer to above discussion of ALT text in 1.1.E
>|
WC:: not sure I would refer to 1.1.E, but it does look incomplete. I have
marked it as needing work.
>|
>
> ==================
>| Technique 1.1.I [priority 1] Check if audio files have an associated text
>| transcript
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * If the target of an A element is a sound file then ask the user if
>LRK:: shouldn't use word "target" since that has special meaning. Use "href".
WC:: done. I sent proposal in e-mail.
>| there is an existing text transcript file.
>LRK:: it doesn't have to be a text transcript file. The text can be on
>the page in which the A element resides.
WC:: done.
WC:: This is as far as I got today. I will try to finish up going through
Len's comments next week.
--wendy
> ==================
>| Technique 1.1.J [priority 1] Check SCRIPT element for associated NOSCRIPT
>| element
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Following a SCRIPT end element, there must be a NOSCRIPT element.
>| * The NOSCRIPT start and end elements must contain at least one valid
>| text element.
>LRK:: must contain HTML which when rendered must produce at least one word
>of text. This e.g. allows an image with ALT text. Also, the tool must
>check the HTML per this document.
>
>|
>| Valid text element:
>|
>| * Must contain at least one word of text
>| * Suspicious - ALT attribute value is placeholder NOSCRIPT text.
>|
>| Example Language:
>|
>| * Language for missing NOSCRIPT: Missing NOSCRIPT element for this
>| SCRIPT element.
>|
>| Repair Technique:
>|
>| * Prompt user for text description of script. Insert a NOSCRIPT section
>| after the SCRIPT with the script description text.
>LRK:: Don't limit to text description. Prompt for HTML that is
>functionally equivalent. This may be, for example, a list of links, form
>input to CGI, etc.
>
> ==================
>| Technique 1.1.K [priority 3] User notification for ASCII art
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| All BODY elements will generate a user notification.
>|
>| Note: We are still working on methods of determining if a document contains
>| ASCII art. If we can't find a suitable algorithm that finds ASCII art then
>| all pages will get a notification.
>
>LRK:: cf. rules rules described in
>http://www.w3.org/WAI/ER/IG/ert/AsciiArt.htm
>
>And statistical tests mentioned in
>http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Jan/0006.html
>
>
>
> ==================
>| Technique 1.2.A [priority 1] Prompt user for text links if ISMAP used.
>LRK:: There's also the case where the same map has a USEMAP, i.e. a client
>side image map. If that's the case, just test for accessibility of the
>client side map.
>
>
> ==================
>| Technique 1.3.A [priority 1] User Notification for audio description.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Any multimedia object will generate a user notification
>LRK:: define multimedia.
>
>|
>| Example Language:
>|
>| * Multimedia presentations should have an associated audio description.
>LRK:: Audio description not always necessary for multimedia. What if the
>multimedia object can be fully described with ALT text or text in the document?
>
>|
>
> ==================
>| Technique 2.1.A [priority 1] User notification for color use
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| Display a user notification if the document contains any of the following
>| elements:
>|
>| * IMG
>| * APPLET
>| * OBJECT
>| * SCRIPT
>| * INPUT
>
>LRK:: Also generate if text color is controlled by FONT or CSS.
>LRK:: Also generate if text contains any color names.
>
>|
>
> ==================
>| Technique 3.1.A [priority 2] User notification for appropriate markup
>| language
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * All BODY elements will generate a user notification.
>LRK:: since this checkpoint only refers to images, why notify for all BODY
>Elements? Why not just Images?
>Also, I don't understand what "All body elements" mean. There is just
>one "Body Element" since that term means the start tag, end tag, and
>everything in between. Do you mean all elements that are part of the Body
>Element's content?
>
>
> ==================
>| Technique 3.2.A [priority 2] Check document for public text identifier
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * The first line of the document must be a valid public text identifier
>| if the document being validated is an HTML document.
>| * A valid public text identifier is... (Haven't got precise definition.
>| Anybody know for sure?)
>| * The document is an HTML document if there is an HTML element near the
>| start of the document and there is an HTML end element as the last
>| non-whitespace text in the document.
>LRK:: (minor language thing) you mean HTML TAG, not element. The
>"element" includes the start tag end tag, and everything in between. At
>least, that what it is in XML...
>
>LRK:: the HTML start and end tags are optional. See
>http://www.w3.org/TR/html4/struct/global.html#h-7.1
>So, hmmm, what do we do? Perhaps check MIME type off the server where it
>will be used.
>
>|
>
>=======================
>| Checkpoint 3.3 - Use style sheets to control layout and presentation
>| Technique 3.3.A [priority 2] Check document for use of style sheets. Notify
>| user if they are not used.
>
>LRK:: only notify user if color or font attributes appear somewhere, to
>avoid crying wolf to someone wants to just present classic unadorned page.
>
>
> ==================
>| Technique 3.4.A [priority 2] Check document for relative or absolute units.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * [incomplete]
>|
>| Example Language:
>|
>| * This element uses absolute units of measure rather than relative units
>| of measure.
>|
>| Repair Technique:
>|
>| * Allow user to change the units of measure.
>LRK:: what if the absolute units are in a style sheet?
>
>|
>
> ==================
>| Technique 3.5.A [priority 2] Check document for header nesting
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Header elements (H1-H6) should be checked to ensure they are neste
>
>
>| according to the following rules
>| 1. The first header element in the document must be H1
>| 2. There must be only one H1 element in the document
>LRK:: Why only one H1? It isn't part of the HTML4 spec , as far as I can
>see in http://www.w3.org/TR/html4/struct/global.html#h-7.5.5
>
>LRK:: HTML4 also allows skipped levels. The spec merely says
>"Some people consider skipping heading levels to be bad practice. They
>accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading level
>H2 is skipped."
>We should point out that we don't skip levels because of accessibility
>reasons.
>
>So actually we have a problem with WCAG: it doesn't define "and use them
>according to specification".
>
>
>
> ==================
>| Technique 3.5.C [priority 2] User notification of improper header use
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * If the document contains any Header elements (H1- H6) that contain a
>| text string longer than 20 words then a user notification is
>| presented.
>|
>| Example Language:
>|
>| * Header elements (H1 - H6) should be used to define headers and should
>| not be used for formatting text.
>|
>| Repair Technique:
>|
>| * Allow the user to convert any header text to another type. Possible
>| types are:
>| 1. Paragraph
>| 2. Blockquote
>|
>| ------------------------------------------------------------------------
>|
>| Checkpoint 3.6 - Mark up lists and list items properly
>LRK:: what does WCAG's "properly" mean, beyond passing HTML validity?
>
>|
>| Checkpoint 3.7 - Mark up quotations. Do not use quotation markup for
>| formatting effects such as indentation
>|
>
> ==================
>| Technique 3.7.A [priority 2] Check document for missing quote markup
>LRK:: Unfortunately, all major browsers, NN, MSIE, and Opera, ignore the
>rendering spec in HTML4:
>
>Visual user agents must ensure that the content of the Q element is
>rendered with delimiting quotation marks.
>
>(cf http://www.w3.org/TR/html4/struct/text.html#h-9.2.2)
>
>So if you follow the command in HTML4 to not put quotation marks at the
>beginning and end of the content of a Q element.
>
>Then the poor visually oriented user sees no quote marks.
>And the user with a screen reader gets no quote marks either, and there's
>less chance that it will recognize <Q> than quote marks.
>
>So in practice <Q> is not presently usable per spec. This rule may be OK
>from a pure HTML point of view but it isn't really practical given the
>state of browsers today.
>
>
>|
>| Checkpoint 5.2 - For data tables that have two or more logical levels of
>| row or column headers, use markup to associate data cells and header cells
>LRK:: not needed if the HTML4 Algorithm
>http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3
>can identify the headers. This is a WCAG issue.
>
>|
>| Technique 5.3.A [priority 2] User notification of using tables for layout
>|
>| Discussion Status:
>|
>| * under discussion
>|
>| Evaluation:
>|
>| * A TABLE element will trigger this evaluation.
>| * The table must have more than one column.
>| * This technique applies only to tables used for layout purposes, not to
>| data tables.
>|
>| Example Language:
>|
>| * Tables used for layout should make sense when linearized.
>| * When a table is 'linearized' the cells are usually read a row at a
>| time, starting at the left and moving to the right.
>LRK:: use definition: Linearization means reading the cells in the order
>they appear in the HTML source.
>
>|
>
> ==================
>| Technique 5.5.A [priority 3] Check table for valid SUMMARY
>|
>| Discussion Status:
>|
>| * discussion complete
>LRK:: I don't understand this guideline. Isn't a caption enough and Table
>headers enough, at least if it's a simple table? A summary would merely
>recite what's in the caption and headers anyway. This is a WCAG issue.
>
>
>
> ==================
>| Technique 5.6.A [priority 3] Check table for header abbreviations
>|
>| Discussion Status:
>|
>| * under discussion
>|
>| Evaluation:
>|
>| * TH elements should have a valid ABBR attribute if the header name is
>| greater than 15 characters.
>
>|
>| Valid ABBR attributes:
>|
>| * Not allowed - NULL ABBR value ("")
>| * Not allowed - ABBR value of spaces (" ")
>| * Suspicious - ABBR value of placeholder ABBR values
>| * ABBR values should be shorter than 15 characters.
>LRK:: The ABBR should be pronounceable, since the purpose is to be read by
>speech technology in the future
>(cf. http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#data-tables )
>
>
> ==================
>| Technique 6.1.A [priority 1] User notification of style sheet use.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * A LINK element with a REL attribute set to 'stylesheet' will generate
>| this notification.
>LRK:: Also: if tags have style attribute set, or <STYLE> element is
>used. (WCAG issue)
>
>
> ==================
>| Technique 6.2.B [priority 1] User notification of dynamic content changes
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * SCRIPT elements will generate this user notification
>LRK:: also, any Javascript, e.g. onmouseover=".... code which changes
>something somewhere..."
>
> ==================
>| Technique 6.3.A [priority 1] User notification of usability when
>| programatic objects are disabled.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Any programatic object will generate this user notification.
>| * Programatic objects are: scripts, objects, or embeds
>
>LRK:: or any javascript e.g. attached to onclick, onmouseover, etc.
>
>
> ==================
>| Technique 6.4.A [priority 2] User notification of device independent event
>| handlers.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Any programatic object will generate this user notification.
>| * Programatic objects are: applets, scripts, objects, or embeds
>LRK:: or any javascript attached to onclick etc...
>|
>
> ==================
>| Technique 6.5.A [priority 2] Check if there is a NOFRAMES section after a
>| FRAMES section.
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Immediately following a FRAME end element must be a NOFRAMES element.
>|
>| Example Language:
>|
>| * No NOFRAMES section following a FRAME section.
>|
>| Repair Technique:
>|
>| * Allow user to construct a NOFRAMES version of the document.
>LRK:: content of the NOFRAME must be checked.
>
>|
>
> ==================
>| Technique 7.1.A [priority 1] User notification of potential screen flicker
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Any of the following elements will generate this user notice:
>| o APPLET
>| o OBJECT
>| o SCRIPT
>| o EMBED
>| * IMG elements will generate this user notice if they are of the type
>| 'animated gif'.
>
>LRK:: Desirable to actually measure flicker. This could be done e.g. by
>software that renders, takes screenshots and compares. Note that this is
>not a requirement for release one of APROMPT .. nor is anything else in
>this document <smile>
>
>|
>| Example Language:
>|
>| * Display flicker is distracting and may be dangerous to some users.
>| Please ensure this element does not cause the display to flicker.
>
>LRK:: how do we quantitatively distinguish between flicker and slow
>changes in images? Is it the 4-59 hz in wcag? What does "quick changes"
>mean? Would "quick changes" mean that you can't bring up a new screen,
>which is a quick change? How big does the area have to be to cause
>trouble? (WCAG issue)
>
>
> ==================
>| Technique 7.3.B [priority 1] Remove any scripts that cause text to scroll
>|
>| Discussion Status:
>|
>| * under discussion
>|
>| Evaluation:
>|
>| * Find any SCRIPTS that cause text to scroll. These scripts can be
>| distinguished by (see discussion)??
>
>LRK:: see above remark about software that renders, takes screenshots, and
>compares.
>
> ==================
>| Technique 7.4.A [priority 2] Remove auto-refresh attributes from META
>| elements
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * 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.
>|
>| Example Language:
>|
>| * This page uses auto-refresh which can make the page difficult to read
>| for some people.
>|
>| Repair Technique:
>|
>| * Allow user to remove the auto-refresh from the document.
>|
>| Test Files and Discussion Files:
>|
>| * Link to test file for this technique.
>
>LRK:: another ditto on remark about software that renders, screenshots,
>and compares...
>
> ==================
>| Technique 8.1.A [priority 1 if functionality is important and not presented
>| elsewhere, otherwise Priority 2] User notification if programmatic elements
>| used
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Search the document for any of the following elements: OBJECT, APPLET,
>| EMBED or SCRIPT.
>|
>| Example Language:
>|
>| * This element may not be accessible to all users. Please ensure there
>| is an accessible interface to this object.
>|
>| Repair Technique:
>|
>| * If any programmatic elements are found in the document, provide a user
>| notification:
>
>LRK:: tool should include means to test the embedded technologies, e.g.
>java, at least by running them, preferably by including any test software
>supplied for the technology.
>
>|
>| ------------------------------------------------------------------------
>|
>| 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
>
>LRK:: or combinations of shapes pointing to same URL (WCAG issue)
>|
>
> ==================
>| Technique 9.1.A [priority 1] User notification of server-side image map use
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * IMG element is a server-side image map if it contains an ISMAP
>| attribute.
>|
>| Example Language:
>|
>| * Use client-side image maps instead of server-side maps.
>|
>| Repair Technique
>|
>| * Allow the user to convert the server-side image map to a client-side
>| image map.
>|
>| Test Files and Discussion Files:
>|
>| * Link to test file for this technique.
>
>LRK:: are there any common formats for the server side information? If
>so, provide means to convert to client side image map.
>
>
> ==================
>| Technique 9.3.A [priority 2] User notification of logical event handlers
>| for scripts
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * Any SCRIPT element will generate this user notification
>
>LRK:: also attributes such as "onclick" ?
>|
>| Example Language:
>|
>| * For scripts, specify logical event handlers rather than
>| device-dependent event handlers.
>|
>| Repair Technique
>|
>| * None
>|
>| Test Files and Discussion Files:
>|
>| ------------------------------------------------------------------------
>|
>
>======================
>| Checkpoint 9.4 - Create a logical tab order through links, form controls,
>| and objects
>
>LRK:: always shown?
>|
>| ------------------------------------------------------------------------
>|
>
>=====================
>| Checkpoint 9.5 - Provide keyboard shortcuts to important links
>LRK:: always shown?
>|
>| ------------------------------------------------------------------------
>
>====================
>| 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
>|
>| Discussion Status:
>|
>| * awaiting discussion
>|
>| Evaluation:
>|
>| * A element opens a new window if it has a TARGET attribute with a value
>| of "_blank" or "_new".
>
>LRK:: actually, any target attribute will create window with that name if
>it doesn't already exist.
>
>|
>| Example Language:
>|
>| * This Anchor element [anchor text] will open a new window that can be
>| disorienting for some users.
>|
>| Repair Technique:
>|
>| * Allow the user to remove the 'new window' attribute from the anchor.
>|
>| Test Files and Discussion Files:
>|
>| * 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:: what are positions?
>Suggestion: labels for radio buttons and checkboxes appear after
> labels for text fields appear in front.
>
> Putting labels for radio buttons and checkboxes first may seem
> inconsistent, but it's needed for reasonable visual rendering, it's the
> most common, and it's more important to stay with what a blind user
> expects than to change it in just a few places.
>
>
>|
>
>=====================
>| Checkpoint 11.1 - Use W3C technologies when they are available and
>| appropriate for a task and use the latest versions when supported
>
>LRK:: This is a wcag issue. Must we insist on W3C technologies if there
>are other standards with good accessibility?
>AFter all in the authoring guidelines we ask for accessibility in the
>non-w3c technologies implementing the editor.
>
>
>======================
>| 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:: again, why insist on W3C?
>
>====================
>|
>| 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?)
>
>LRK:: I like that
>
>=======================
>|
>| Checkpoint 14.3 - Create a style of presentation that is consistent across
>| pages
>|
>| (Can't be machine checked. User notification?)
>|
>| ------------------------------------------------------------------------
>|
>| Document Rating
>|
>| After evaluating a document, an evaluation and/or repair tool should
>| provide the user with a document rating. The rating is based on conformance
>| to the WAI Page Authoring Guidelines and will be:
>|
>| * Level "A": all Priority 1 checkpoints are satisfied;
>| * Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;
>| * Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied;
>|
>| Some checkpoints can not be checked by a software program and will require
>| user evaluation. The user must be informed of the items that they must
>| check.
>LRK:: Link to or incorporate algorithm at
>
>http://www.w3.org/WAI/ER/IG/rating/
>
>
>========================
>|
>| Appendix L - Links To Associated Sites
>|
>| * Bobby - Accessibility evaluator tool
>| * Lynx Viewer - Displays a text-only view of web pages
>| * A-Prompt - Accessibility evaluator and repair tool
>LRK:: The Wave (when LRK puts it on the web)
>
>
>|
>| ------------------------------------------------------------------------
>|
>
>-------
>Leonard R. Kasday, Ph.D.
>Institute on Disabilities/UAP, and
>Department of Electrical Engineering
>Temple University
>423 Ritter Annex, Philadelphia, PA 19122
>
>kasday@acm.org
>http://astro.temple.edu/~kasday
>
>(215) 204-2247 (voice)
>(800) 750-7428 (TTY)
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--
Received on Friday, 4 February 2000 17:58:20 UTC