Comments on September 28 draft

Here's some comments on the WCAG draft. I haven't been following the process
closely so I apologize if I say something that's already been discussed to
death. Things that I don't mention here I thought were fine, though I think
the suggestions in the open issues list have merit.

2.2: "Use style languages..."

We might want, in this or another checkpoint, to say "use markup in such a
way that user-defined stylesheets will work well." What I'm getting at is,
if an author makes structural differentiation on the basis only of class
attributes or something, a typical user style sheet, which will only
reformat standard markup, might not see the differences. As much as
possible, "plain" markup should be employed to maximize the effectiveness of
user-defined style sheets.

3.2: "Use color, style, graphics to emphasize structure..."

I think this is an important thing. In my experience, however, it has the
_appearance_ of colliding with other guidelines (make sure colors contrast
well, stylesheets degrade gracefully, graphics have textual alternatives,
etc.). People don't get on first reading that it's actually saying "use
color etc. but use it per other guidelines". A suggested wording might be
"Use color, styles, and graphics, following applicable guidelines, to
emphasize the structure of the document." The explanation block can go into
that a bit, I can write a suggestion of people take this up.

3.9: "Define key terms... abbreviations and acronyms..."

It says only the first instance needs to be expanded. I just need clarity on
why that is. Is it because it is from then on the user agent's
responsibility to know that it has been expanded, and know to present the
expansion? Or is it on the theory that the user has already encountered the
term and doesn't need it expanded again? I suggest that that might not be
true for users with cognitive disabilities. Also, what if the user was
skimming on the basis of structural elements or something? They might not
have encountered the term where it was first expanded, and then be confused.
If it is the user agent's responsibility to take care of that, these aren't
issues, but I haven't seen anywhere that it formally is, and it might be a
little much to expect them to identify repeat occurrences of something in
the text stream that is not set apart with markup.

4.1: "Provide... navigation mechanisms..."

Perhaps in the explanation of this, or _maybe_ as a new point, I would add
"Provide clear notification on each page of the user's location within the
site structure." I think that's important not to have the "lost" feeling
especially when landing on a page as a result of a search.

5.3: "Use device-independent event handlers"

It asks for examples. First is "active" (CSS pseudoclass) or "onactivate"
(scripts) - should be triggered by either a mouse click, the enter key, or
whatever other device function, though it isn't yet widely supported in
browsers as being different from "onmouseclick" or "onkeypress". There are a
number of DOM 2 events that _might_ qualify too: load, unload, abort, error,
select, change, submit, reset, focus, blur, resize, scroll. In ER we suggest
keyboard events as qualifying (focus equals mouseover), but that is actually
just dependent on a different, more common, device and perhaps those
shouldn't be included here.

6.2: "Avoid... blink or flicker..."

First, the rationale for this should be in this document, and could be
pretty much the same as in WCAG 1.0. Second, this seems to overlap with
3.10: "Minimize content that will interfere with the user's ability to
focus." Maybe they should be combined, or 6.2 should be reworded to apply
only to blinking/flickering that triggers seizures or freezes browsers, and
the distracting effects of blink/flicker left in 3.10. If you want wording
suggestions I'll put something together.

6.3: "Avoid causing pages to be refreshed..."

This seems to be pretty much covered in 4.3: "Avoid methods that interfere
with navigation", so I'd be inclined to remove this. Perhaps in its place,
we should say "Provide alternate means of navigating to the target of page
that is redirected automatically" - which is an issue and more in line with
Guideline 6 (backwards compatibility).

6.4: "...enable the content to be processed..."

I found the wording of the explanation hard to parse. How about "This
requirement is espeically relevant when using a data format or markup
language that is not widely supported in user agent software. Note also the
discussion of backward compatibility in checkpoint 5.1."

Lastly, two issues that weren't addressed that I think should be:

Target size. Small target areas (created by small linked images or small
image map regions, or in programmatic objects) for pointing devices should
be avoided, as they can be difficult for people with manual disabilities to
get to. I know it's possible to tab to such links but it is usually not
convenient to do so for people who interact with the page spatially rather
than serially. I also see that sort of thing might be more specific than the
group wants to get in this guideline set, but I think it can fit in pretty
well. Therefore, I propose a new checkpoint under Guideline 4 to read:

[title] Do not use small pointing device targets.
[explanation] Links or other functionality that depend on moving the
pointing device to a small target may be difficult to reach. Users with fine
motor difficulty or high screen resolution may require several tries to
reach the target. When possible, targets should scale with the rest of page
if the user chooses. Targets that are dependent on absolute pixel sizes,
such as linked images and image map areas, should not be smaller than 5
pixels in either the vertical or horizontal dimensions, and should enclose
at least 30 pixels. [MC: those numbers are arbitray, and on the small side I
think]

Second, the issue of allowing the user flexibility in font size, typeface,
and color doesn't seem to be particularly addressed. I especially did not
notice a prohibition against the use of absolute sizes. Perhaps it was left
to the user agent to ignore absolute sizes at user preference? Opera is the
only one I know that does (and Lynx of course for different reasons); MS IE
does too but at the cost of losing all relative size differences, which may
convey meaning, between different pieces of text. Or perhaps it is expected
that the guidelines essentially forbid deprecated elements like <font>, and
mandate replacable stylesheets so that isn't an issue? I'm not sure that's
likely to be widely implemented in the near future, and anyway I think the
guidelines should mention the issue so authors are aware of it. I could see
this issue as being distributed among several checkpoints, or presented as
new checkpoints, and will make suggestions on that if people agree it should
be there.

That finishes me off for now...

Michael

Michael Cooper
Bobby Project Manager
Technical Designer
CAST, Inc.
39 Cross St.
Peabody, MA  01960
Tel +1 978-531-8555 x265
TTY +1 978-538-3110
Fax +1 978-531-0192
Email mcooper@cast.org
http://www.cast.org/
http://www.cast.org/bobby/

Received on Thursday, 5 October 2000 13:56:41 UTC