FW: Comments on W3C WAI PA

Here is some feedback from Greg Lowney, Microsoft's Director of
Accessibility, on the guidelines.  More feedback from Microsoft is
forthcoming.

I will ensure that Greg is made aware of any comments.

Charles Oppermann
Program Manager, Microsoft Accessibility and Disabilities Group
http://www.microsoft.com/enable/

>  -----Original Message-----
> 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.
> 
>

Received on Monday, 8 March 1999 16:22:40 UTC