- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 22 Mar 1999 10:23:37 -0500
- To: Greg Lowney <greglo@microsoft.com>
- CC: w3c-wai-gl@w3.org
Greg Lowney wrote:
>
> 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.
It was not too late at all! Thanks for the comments.
Some of your comments were resolved at the 17 March teleconference [1],
some at the 11 March teleconference [2].
Others were discussed during an 18 March telephone call that will
be the basis of discussion during the 22 March teleconference [3]
[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0466.html
[2] http://www.w3.org/WAI/GL/meetings/19990311.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0469.html
Please note that [1] and [2] refer to the 26 February public draft [4]
while [3] refers to the 16 March WG draft [5]
[4] http://www.w3.org/TR/1999/WD-WAI-PAGEAUTH-19990226
[5] http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19990316
> 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.
The guidelines should not refer to specific implementation issues
since they are meant to be abstract. The Techniques document will
provide some information about where browser details may be found.
> 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?
Resolved in [2], item 5.
> 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.
Resolved in [2], item 5.
> 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.
Discussed 18 March, see [3].
> 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?
Discussed in [2]. Priority kept as 2. Wording changed to:
Use header elements to convey logical structure and
use them according to specification.
> 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.
Discussed in [1]. Not an editorial issue but one of markup, so
resolved wording:
Mark up lists and list items properly.
> 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.)
Discussed in [1]. Decided to keep Priority 2 with some
additional rationale.
> 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.
No minuted discussion. Leaving as Note in section 9:
The BLINK and MARQUEE elements are not defined in any W3C
HTML specification and should not be used.
> 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.)
Discussed 18 March, see [3].
> 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?
(Guideline 11 in [4]).
I don't know that having an "A" around an object is a basic
requirement for elements that take input.
a) What about forms?
b) In other user agents such as Opera, you can navigate to every
element.
I'm not sure what's being requested here.
> 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.)
This was discussed in [1] and [3] and the results are:
a) Checkpoint 5.1 will read:
Use header elements to convey logical structure and use
them according to specification.
b) After discussion of [3], a new checkpoint in guideline 14
should read (and refer to headings as an example):
Divide large amounts of information into
manageable groups where natural and
appropriate.
> 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.
During [3], we discussed creating a new checkpoint about
organizating information. Your comment about FIELDSET
is subsumed by the new checkpoint, which is priority 2.
> 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).
Yes. This was discussed at [1] and we decided to word checkpoint 15.1
as follows: Clearly identify the target of each link. We will add
that "title" may be used in addition to clear link text to make
links understandable outside of context.
> 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>.
Yes, we can use this information - removing browser-specific
information - in the techniques document.
> 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.
This was discussed in [1]. Resolved:
* Use W3C technologies and use the latest versions
when they are supported. [Priority 2]
> 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.
This was discussed in [1]. Resolved:
* Avoid deprecated features of W3C technologies. [Priority 2]
> B.1.5 Use of OPTGROUP should be Pri 3 as it improves usability but not basic
> accessibility.
Discussed in [1]. Resolved to create a single checkpoint
that has to do with grouping (priority 2).
> 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.
I will add this to the issues list.
> Lower Priority:
>
> A.2.1 Does it describe how to make D links reliably invisible?
The techniques document will discuss this.
> A.3.3 What exactly is meant by played automatically? Only startup sounds, or
> also sounds played automatically in response to user input?
I will add this to the issues list.
> 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)?
The guidelines[5] now say to use the "summary" attribute for this.
> A.8.3 May want to add note that it's appropriate to override the styles so
> the TH etc. don't look abnormal.
Here's the checkpoint in question in [5]
For data tables, identify headers for rows and columns. [Priority
1]
For example, in HTML, use TD to identify data
cells and TH to identify headers.
What does "abnormal" mean?
> A.9.3 I'd recommend listing a third alternative mechanism, something simpler
> like "text links".
In [5], this checkpoint (8.2) reads:
For scripts that present important information or
functionality, provide an equivalent. [Priority 1]
For example, in HTML use NOSCRIPT or a server-side
script that outputs the equivalent.
a) Would links appear within a NOSCRIPT or outside of it?
b) What would the links refer to? If it's an alternative page,
this is covered by 13.4, which is referred to from checkpoint 8.2
> 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.
Done.
> B.2.10 This should be the UA's job, but since it's PRI 3 I guess it can
> stand.
Agreed. The wording "until user agents ..." has been added.
> B.3.1 Seems very unrealistic.
a) This checkpoint (16.1 in [5]) currently reads):
Use language that is clear and simple,
yet appropriate for the site's content.
b) Though admittedly subjective, this was considered very important
by the WG to address cognitive disabilities.
> 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.
a) Given the intentional guidelines/techniques division, I'm not sure
this comment is accurate.
b) We provide a zip archive and gzip archive, which the guidelines
do say is an appropriate option for offline browsing.
Thank you for the comments Greg,
- Ian
--
Ian Jacobs (jacobs@w3.org)
Tel/Fax: (212) 684-1814
http://www.w3.org/People/Jacobs
Received on Monday, 22 March 1999 10:24:58 UTC