Re: Comments on W3C WAI PA

Greg, looking more closely at your comments, it seems that you've not
reviewed the latest version of the guidelines:
  http://www.w3.org/TR/WD-WAI-PAGEAUTH/

I don't think you looked at a very old version, so it shouldn't be too
hard to map your guidelines refs (A.12.3, B.1.2, etc) to the more
recent numbering, but it would help if you sent us the exact release
date of the document you reviewed.

Thanks



> 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 Tuesday, 9 March 1999 08:28:21 UTC