review of 19990903 draft

Hello,

right on!  This document has come a long way, baby!  <grin> (reference to
an ad in the U.S.)

Here are my comments about both the Guidelines and Techniques since I read
them together.  

It looks like the bullets for Techniques were pasted into the Guidelines
document.  The two documents need to be more distinguished from each other,
particularly in the front matter.  for example, the Techniques document
still says, "How the Guidelines are organized."  I like that selecting a
"techniques link" from the Guidelines document sends you to specific info
for that checkpoint, but the rest of the document needs to show some
differentiation.  Also the rationales for each Guideline could get into
more detail in the Techniques document.  Also, more detail could be given
for each Technique.  

In general, I think that the checkpoints with relative conformance levels
(1.2, 1.3, 3.1, 4.1, 4.2, 6.3, and 7.1) need to be explained further and
have accompanying examples in the Techniques document.

Can 2.3 really be a P1??  Is there a list of languages that "enable
accessibility?"  What about document formats like PDF, Flash, and etc.  If
the tool is able to create an equivalent that is accessible but the format
(language) itself does not "enable accessibility" is the tool not compliant?

The technique for 3.1 needs to be clear that null equivalent info is used
for only a constrained set of circumstances (which is still under
discussion in the WCAG working group).  I would point to the section of the
WCAG techniques document where this is discussed
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#text-equivalent.  The list of
prompts under 3.1 is not complete.  Either it should be stated that this is
not complete and direct the reader to the rest of the info or it ought to
be completed.


The example commonly given throughout the techniques document for
alternative text is providing "alt" for IMG.  It seems that we ought to be
encouraging developers to use the OBJECT element and alternative content
therein.  For example, see checkpoint 3.2 and 5.1.

In the discussion of 3.4 in the Techniques document, why is the acronym for
"alternative information mechanism" ACM?

Checkpoint 4.1 and 4.2 do not seem worded quite right.  First of all, 4.1
says, "Check for and alert..." not all of the checkpoints in WCAG can be
automatically checked for - as implied in the Techniques doc in reference
to the ER list, but maybe it should be more clear in the checkpoint text?
We might want to point to Bobby as an example, since they have been working
on this issue for a while.  Secondly, the priority levels, "Priority 1 for
accessibility problems that are [Web-Content-Priority-1]" seem a bit off.
In WCAG the priority level is given to a solution not to a problem,
although it is related to how difficult it is for someone if that
checkpoint is not followed.  A very minor point, but it could confuse
someone and doesn't quite sound right.  However, I don't have a proposal.

4.5 in the techniques it says, "SPAN into RUBY."  what is RUBY?

One of the coolest things that I have seen authoring tools do is indicate
the level of browser support of a particular HTML or CSS element or
attribute.  For example, HomeSite/TopStyle will let me change which browser
I am authoring for.  In doing so, certain attributes may not be available
on my pallette if I am authoring for Netscape vs. IE.  It also has several
checks that I can run to determine which elements or attributes may be
problematic.  Some tools indicate potential problems by placing an icon
next to the element/attribute, others generate reports.  Others will give
you previews of a variety of browsers.  I expected to see these types of
techniques somewhere in the Techniques for checkpoints of Guideline 4.  Did
I miss them?  Bullet point 8 under 4.1 (in the Techniques doc) is pretty
much it but needs more explanation.

In the Techniques document, checkpoint 6.3 ought to have a couple HTML
examples to clearly show what is intended.  Particularly in reference to
the phrase, "An example may be built from several parts, some of which are
not themselves conformant, so long as those parts are identified and linked
to a conforming example." 

Checkpoint 7.1 states that it is, "Priority 1 for standards and conventions
which are essential to accessibility, Priority 2 for those that are
important to accessibility, Priority 3 for those that are beneficial to
accessibility."  I had expected to find a list of "standards and
conventions which are essential to accessibility" in the Techniques
document.  Instead, there is a nice list of references as well as a list of
"common requirements for producing accessible software."  However, as a
developer I think I would be looking for more guidance as to how to satisfy
the priority of checkpoint 7.1.  Looking at some of the resources in the
list, other than WCAG, I don't see that they are prioritized at all or the
same way.

In this list, [SUN-DESIGN] is a broken link.

Also, 7.1 has 3 relative priorities but is Priority 1 overall, is that
correct? the other checkpoints with relative priorities only have the 3
relative priorities.


wendy chisholm
human factors engineer
trace research and development center
university of wisconsin - madison, USA

Received on Wednesday, 8 September 1999 13:18:33 UTC