- From: Kynn Bartlett <kynn@idyllmtn.com>
- Date: Mon, 22 May 2000 14:20:51 -0700
- To: w3c-wai-er-ig@w3.org
Feedback on "Techniques for Accessibility Evaluation and Repair Tools"
By Kynn Bartlett <kynn@edapta.com>
Director of Accessibility, Edapta Inc.
22 May 2000
These comments are based on the 26 April 2000 draft of AERT
(http://www.w3.org/TR/2000/WD-AERT-20000426)
Specific feedback follows.
To Do list:
1. The term "author" is preferable here to "user" -- as with
the Authoring Tool Accessibility Guidelines, "author"
should refer to the person creating/preparing content for
the web, and "user" to the end user, even if the author
is a "user" of specific software.
Introduction
1. The specific purpose of this document is unclear to me; while
I understand what it does, I am unable to discern the exact
scope and goals of AERT. The use of priorities (inherited
from WCAG) and of "absolute language" in many guidelines
make this sound as if it were a normative document, not a
list of suggestions.
2. Is the goal to be a "collection of good things to do", a "list
of minimal functionality", a "comprehensive list of every
way to evaluate a web document" or something else? The
answer will have a definite effect on the software tools
developed and how they use this document. If this strives
to be a "definitive listing," for example, this could adversely
affect the ability of companies to produce commercial ERT
tools that have competitive advantages.
3. An explanation of this document relates to the Authoring
Tools Accessibility Guidelines and techniques would be
useful -- otherwise the possibility for confusion exists.
Structure of this Document
1. The nature of the inherited checkpoint priorities needs to
be addressed -- is the listing of WCAG priorities meant to
be merely informative or are ERT tool creators expected to
follow those?
2. When a repair strategy is suggested, it should be made clear
that the options provided are not the only ones that could
be made available to an author -- and in all cases the author
should have the ability to override the tool at any point
in the process.
Technique 1.1.1:
1. NULL "alt" values (alt="") should be allowed.
2. The use of the term "suspicious" is, well, suspicious, or at
the very least could be avoided. In English, this word has
a connotation of "deceit" and "guilt" that are not appropriate
for suggested messages or even for internal use. A better
term should be selected, such as "Potential Accessibility
Problem" or "Requires Manual Check", which are value-neutral.
3. The suggested message for missing text equivalent should
explicitly mention the "alt" attribute, simply because many
web designers are likely to be familiar with the term.
Revised suggested message: Missing text equivalent ("alt"
attribute) for image.
4. Suggested text for "longdesc", however, will always need
further explanation, as this attribute is not familiar to
most web authors, and can lead to confusion easily -- for
example, many people will incorrectly guess that "longdesc"
is simply a longer text string, a la "alt", rather than
a URI reference.
5. Do not suggest "bullet" for bullets and "horizontal rule"
for horizontal rules. Instead, suggest one of the following:
a. Convert the bullet/horizontal rule image to list
markup (UL and LI) or horizontal rule markup (HR),
with appropriate use of CSS to preserve use of the
image; or
b. Suggest "*", "o", "-", and "+" as acceptable "alt"
text for bullets. @@ Needed: Appropriate "alt" text
for horizontal rules -- this may be best served by
NULL "alt" attribute.
Technique 1.1.2:
1. Authors who have already provided "alt" text may be confused
by the use of "description of the image" in the suggested
message -- "Didn't I already provide that?" will be a common
response to authors familiar with "alt" but not with "longdesc".
The suggested message should, at the very least, refer to the
fact that a separate page is used for this purpose -- most
authors will not realize this.
Technique 1.1.3:
1. See 1.1.1 comments.
Technique 1.1.6:
1. It may be helpful to search for link text containing the
word "transcript"?
Technique 1.1.7:
1. An additional repair option would be to allow the user to
reference an outside page that contains the text
transcript, rather than embedding the text equivalent;
this reference would then be embedded as a link within
the OBJECT element.
Technique 1.1.8:
1. How is it determined if "the relationships between the
frames are apparent"?
Technique 1.2.1:
1. If the hotspots on an image map can be determined, the
TITLE attributes of pages referenced by the hotspots *may*
provide useful suggestions for "alt" text.
2. Bouncing requests off a server should be avoided unless
requested by the author, because overuse of this technique
may lead to traffic problems. (An image that is 468 by
60 pixels in size could generate up to 28,080 requests if
this technique is misapplied.) Spacing of at least 5-10
pixels apart in a grid pattern may be more useful; if a
hotspot is missed, this may indicate a different accessibility
problem related to users without fine motor control.
Technique 1.5.1:
1. See 1.2.1 comment #1.
Technique 2.1.1:
1. A tool may be able to generate a "monochrome" version of the
page with all color formatting removed (and possibly images
converted according to a set of filters) -- this would be
useful for visual inspection by the author.
Technique 3.1.1:
1. The suggested message is problematic -- as a quick example,
MathML support is poor enough that a web site that provides
arithmetic tutorials for children would not want to rely
MathML for rendering of algebra equations.
Technique 3.2.1:
1. An XML document may not require a !DOCTYPE statement.
2. The suggested message -- "Missing language identifier for
this document" -- is too vague because it sounds like it
is referring to the "lang" attribute.
Technique 3.3.1:
1. Should the CSS be validated if identified?
Technique 3.6.1:
1. DL tags are not followed by LI elements, they are followed
by DT and DD. Proper use of these elements can be checked
for, and irregular use of DT/DD can be flagged.
Technique 3.7.1:
1. Suggesting Q will always be disaster. Why does this
element even exist?
2. The suggested identification #1 is problematic because
not everything inside quotes should be marked up with
Q/BLOCKQUOTE.
3. For suggested identification #2 -- what defines "indented
text"?
Technique 3.7.2:
1. Not all quotes longer than 10 words should be marked up
with BLOCKQUOTE; this metric does not make sense.
2. Even if it made sense in English -- what are the i18n
issues connected to the use of quotations?
Technique 4.2.1:
1. Your understanding of abbreviation ("any word greater
than 2 characters that is all capital letters") and of
acronym ("starts with a capital letter, contains lower
case characters and ends with a period") do not mesh
with mine -- in fact, I consider your definitions to be
reversed. However, much discussion on this topic has
yielded the consensus that there is no consensus on the
proper use of ABBR/ACRONYM! Thus, identification rules
such as these should be avoided.
2. The first suggested repair seems to imply that a definition
should be given on every use of the of the abbreviated form;
this is not my understanding.
3. It is possible to identify abbreviated forms through the
use of Inline Natural Language Abbreviation Definitions
(INLAD), and this should be accounted for in this technique.
Abbreviated forms within parentheses should probably be
ignored?
Technique 5.4.1:
1. An additional repair function would be to allow repositioning
and reordering of tables.
Technique 6.1.1:
1. Generate and/or display a version of the page without
styles.
Technique 6.2.1:
1. Relying upon a set of file extensions is a poor choice for
this. There is no requirement that a file must have a particular
name to be a valid markup file.
Technique 6.5.1:
1. The suggested message/question is poorly phrased -- it won't
make sense to most web designers, most of whom are unfamiliar
with the idea of "frames not loading". The question almost
sounds like you are asking "If the page doesn't load, can you
still use the page?"
2. It may be possible to check the NOFRAMES element a little better
by comparing the number of links and their destination to the
content of the various frames. All links accessible through
the framed page should be accessible through the NOFRAMES
section -- except that separate pages/URIs for framed/non-framed
pages might prevent this. The numbers can be counted, however;
a NOFRAMES section with only 3 links compared to a framed version
with 30 links is a good sign that navigation links are not
present. (Also, the text of the links, not just the destination,
may be considered.)
Technique 7.2.1:
1. An equivalent for BLINK is defined in CSS Level 2 -- as a
substitute for BLINK, the following may be used as well as
those listed in the repair suggestion:
<SPAN STYLE="text-decoration: blink;">
As this is part of an official W3C specification, it should
not be ignored.
Technique 7.3.1:
1. An alternative is to provide a scripted solution -- this has
the advantage (as does the BLINK suggestion above) that it does
not restrict the author's creative decisions. If they're
using MARQUEE, it's not by accident -- it's because they want
(or wanted) a scrolling text bar.
Technique 7.3.2:
1. Why is this presented as a Priority 1 checkpoint? WCAG 7.3 is
Priority 2.
Technique 7.5.1:
1. The use of HTTP headers -- via web server configuration and/
or server-side scripting -- should be presented to the author as
an option.
Technique 8.1.1:
1. The suggested message is not helpful. It is far too cryptic
and cryptic messages should not be suggested. Many authors
will have copied/imported/borrowed/"stolen" applets for use
on their pages and have no way to evaluate whether or not there
is "an accessible interface" to the object.
Technique 9.3.1:
1. Adding handlers should be suggested; replacing handlers should
not, due to browser support issues. Changes should never be
suggested that will break the user experience for the majority
of site users!
Technique 9.4.1:
1. This check should likely be invoked only if there are more than
a few links. There is little point in TABINDEX for pages with
only a few tab-able elements.
Technique 9.5.1:
1. Likewise, there is not a need for ACCESSKEY on *every* page,
just *most* pages.
2. If ACCESSKEY is used, the specific access keys need to be
identified and instructions given on how to use them. This
should be included as part of the evaluation -- "have you told
your users how to access the ACCESSKEYs on this page?"
Technique 10.1.1:
1. We must not "completely avoid new windows" -- instead we must
tell the author how to make them accessible.
2. Why is this Priority 1? WCAG 10.1 is Priority 2.
Technique 10.1.2:
1. Why is this Priority 1? WCAG 10.1 is Priority 2.
Technique 10.2.1:
1. With the use of the LABEL element, is there a need for labels to
be placed beside the associated form control? That is not
obvious to me from reading WCAG/WCAGTECH. Is this addressing
those LABEL elements?
2. I don't recall seeing the "rules" associated with locating
labels (as described in the repair suggestion) in WCAG/WCAGTECH
-- if these are useful, then they should be folded back into
WCAG and should not be accessibility guidelines spontaneously
generated by this document.
Technique 10.4.1:
1. Why do "checkbox" or "radio" boxes require at least one word
of text in "value" attributes? There is no need for such a
restriction.
2. "Radio" boxes should have at least one value that is CHECKED.
Technique 10.5.1:
1. Does markup count as "non-whitespace"? Images, for example,
may be used as separators. Can they have NULL "alt" text,
which may render them as "whitespace" on some browsers? What
about the following?
<A HREF="a.html">Apples</A>
<SPAN TITLE="or"/>
<A HREF="b.html">Bananas</A>
<SPAN TITLE="or"/>
<A HREF="c.html">Carrots</A>
This may be a question I should be referring to WCAG. (See my
comments about AERT 10.2.1.)
Technique 11.1.1:
1. It may be irresponsible to simply present W3C technologies and
imply that this will increase accessibility when in fact the end
result will be denying access to 99.99% of the audience.
Technique 11.2.1:
1. Why would we want to suggest that IMG should be replaced with
OBJECT? That falls under the category of "grossly irresponsible
suggestions which work on paper but fail in practice."
Technique 11.3.1:
1. Some of these suggestions may decrease accessibility if used
irresponsibly.
Checkpoint 12.3:
1. A possible technique would be to check to see if the size is
over a certain limit -- say, 50K of text -- and then ask if the
page should be split along lines inferred from H1..H6
structure.
Technique 12.4.1:
1. Also there should be a check to ensure that the "id" value
is unique. (This is part of having a valid "id" attribute,
so perhaps it is assumed.)
Technique 13.2.1:
1. Why are "more" and "follow this" considered suspicious?
2. Article names -- especially academic articles -- may easily
have anchor text that exceeds 60 characters. The phrasing
"should be shortened" is too absolute in the suggested
message.
Document Rating:
1. Effective, worthwhile tools will not rely merely upon the
WCAG conformance levels and should ideally provide several
other optional methods of rating accessibility.
Appendix B:
1. Images can have any suffix -- what matters is the mime type
returned by the server, not the "file name" part of the
URI. For example, http://www.kynn.com/+guilt is an image.
Also, many image formats are not listed here.
Appendix D:
1. See Appendix B comments.
--
--
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/
Received on Monday, 22 May 2000 18:24:17 UTC