Comments on W3C WAI PA

I know it's last minute but better late than never. Here are some comments
on my read through of the guidelines document.  I apologize if any of these
are ignoring things you've already discussed on the listserv.

High Priority:

A.1.3 Anything about the fact that you have to use TITLE on AREA to work
with IE4 or IE5? It is very unfortunate, and really the fault of IE, but
pages only using ALT as these guidelines recommend will not be accessible
with IE, whereas if the page used both ALT and TITLE it would be accessible
with all browsers. I recognize that that would be adding a hack to work
around a flaw in a specific browser, so may not be appropriate, but
certainly Microsoft's version of these guidelines would have to recommend
authors use both.

A.1.4 Redundant textual links for client-side image maps seems like it
should only be pri 3 because we assume the person can find a UA that support
keyboard access to client-side image maps. That is, it's no more important
than avoiding hard-coding colors, which our UA also allows you to override,
and you dropped that one altogether because of the readily available
workaround. Or is this really important for people with cognitive
impairments, and if so, should that rationale be called out?

A.1.5 As with A.1.4, it should be ok to use client side image maps as long
as there is ALT on the AREAs so we should reduce priority to 3.

A.5.2 This should be Pri 1 if A.5.1 is not done correctly, but only Pri 3 if
A.5.1 is done correctly. Making this high priority implies that you have to
do both, which I don't feel is true.

A.6.1 Using Hx tags correctly to convey structure is important, but nesting
them correctly is not in my opinion. I'd say Pri 3. Can you justify why this
is higher priority? 

A.6.2 Using OL and UL is Pri 3--it does not provide access, only makes it
easier. After all, who's to say what lists cross the line from where it's ok
to put them in a sentence, say, or as multiple sequential paragraphs,
instead of as bulleted lists. That seems to intrude on editorial decisions
and so should be recommendation only.

A.6.3 In discussing this with our Web team, I recommend that it is higher
priority to make sure that pages can be used when style sheets are turned
off than it is to avoid abusing BLOCKQUOTE. Therefore if it's important that
a paragraph be set off (e.g. indented) I'd use BLOCKQUOTE instead of relying
on style sheets. What aids or other tools would be adversely affected in
real life by this? (Remember, these guidelines are about improving
accessibility, not enforcing W3C recommendations in general.)

A.10.4 There is no A.10.4 but I'd suggest that the Note 1 about is important
enough to be listed as a Checkpoint because they are so frequently used and
because the general injunction to avoid non-W3C-approved HTML constructs is
not specific enough to make people follow it everywhere. Also, A.10.2 and
A.10.3 can be interpreted as prohibiting BLINK and MARQUEE but they are
vaguely enough worded that they can also be interpreted otherwise. (For
example, does A.10.2 prohibit blinking, or just blinking that causes
flicker? I would rephrase it to clarify that the two clauses are separate.)

A.12 It does not list the basic requirement that there be A around any
object that takes mouse input, which seems very important and should be
added. At least, that's how you do it for IE, and I assume that other UA
would also support this. Is there some other, more browser-independent way
to make sure things that take mouse input are keyboard accessible?

B.1 I would add a Pri 3 recommendation that they use Hx elements to
distinguish structure of the document, although I recognize that it is not
enforceable in a programmatic way. (It seems somewhat ironic that we think
they're important enough to require them to be nested properly, but not
important enough to recommend they be used.)

B.1.3 FIELDSET should only be required (PRI 1) for check boxes if their
labels don't convey enough information to make them understood on their own.
In other cases it might be lower priority, especially if there are few
options in a group.

B.2.1 I strongly suggest that you add requirement that when link text can't
be reasonably worded so as to be understood out of context, that TITLE be
used to add longer names for the links that would distinguish them from each
other. This is a very powerful technique and of much benefit to accessibilty
aids and other tools (such as those that provide a list of the links in a
page).

C. This should include explicit steps that testers can take to evaluate
their sites manually, such as (a) run with CSS turned off (in IE3), (b)
override colors in IE4+, (c) navigate by keyboard, etc. You can find out set
of steps on <http://microsoft.com/enable/dev/web_guidelines.htm>.

Medium Priority:

A.14.1 Seems like a Pri 3 to me; why is that a Pri 2? In fact, in many cases
the opposite is more beneficial.

A.14.2 Also recommend it being demoted to Pri 3, as it doesn't necessarily
cause accessibility problems. If the only problem is one of compatibility
with screen readers, then the fact that a good number of UA (like IE, using
Active Accessibility, or future UA which could put a default placeholder in
as an option) don't have that problem would seem to relegate it to lower
priority. 

B.1.5 Use of OPTGROUP should be Pri 3 as it improves usability but not basic
accessibility.

B.2.9 I still say reserved class names like "nav" are a horrible hack that
should be replaced by a new attribute. What if you have two different nav
bars with different styles, such as bars for the first- and second-tier
tables of contents? Can't do it using these guidelines.

Lower Priority:

A.2.1 Does it describe how to make D links reliably invisible?

A.3.3 What exactly is meant by played automatically? Only startup sounds, or
also sounds played automatically in response to user input?

A.8.1 Just out of curiosity, why still no table attribute specifying whether
it's for layout only etc. (as I'd recommended a long time ago)?

A.8.3 May want to add note that it's appropriate to override the styles so
the TH etc. don't look abnormal.

A.9.3 I'd recommend listing a third alternative mechanism, something simpler
like "text links".

A.13 I'd suggest re-ordering to put the Pri 2's ahead of the Pri 3's, lest
people stop reading after hitting the first Pri 3.

B.2.10 This should be the UA's job, but since it's PRI 3 I guess it can
stand.

B.3.1 Seems very unrealistic.

Other comments:

B.2.8 The guidelines document violate their own rules by not providing the
complete set of guidelines as a single HTML file.

	Thanks,
	Greg Lowney

Received on Monday, 8 March 1999 23:25:56 UTC