- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 06 Dec 1999 09:35:07 -0500
- To: "Martin J. Duerst" <duerst@w3.org>
- CC: w3c-wai-ua@w3.org
"Martin J. Duerst" wrote:
>
> Dear Working Group,
>
> Here are some comments on issues not related to internationalization
> that I found when reading your User Agent Accessibility Guidelines 1.0.
>
> They are ordered more or less from high-level to low-level.
> - The range of browsers available currently is large, and is getting
> larger. The guidelines are largely written for general-purpose graphical
> desktop browsers, but this term only appears once 'en passant'.
> It should be very clearly said at the beginning that this is the
> core target, and how the guidelines apply to other cases.
> The intent of the guidelines was probably more general, but
> it is extremely difficult to be really general, and admitting
> that clearly early on may make it much easier for people to understand
> how to apply the guidelines in each case, and may significantly
> reduce dangerous and costly misunderstandings.
I will take this into account as I edit the abstract for the
next release (today).
> - The text on 'applicable checkpoints' is crucial to understand
> how to apply the guidelines in various cases. It should be
> moved to section 1 to make sure it gets read early on, and
> to show that it is part of the definition of the guidelines.
It used to appear in the section on conformance but the WG
chose to move it to the glossary. However, many reviewers have
focused on the definition and I strongly agree with your suggestion.
Refer to issue #119
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#119
> - Several guidelines are virtually identical or very close to
> general UI guidelines. This observation should be made early
> on.
A couple of comments here:
1) Several reviewers have wished that UI checkpoints (and Guidelines
I suppose) be distinguished from content-related checkpoints.
The solution we have in mind (identifying classes of checkpoints
as UI- or content-related within the existing guidelines) may
contribute to your suggestion that some are close to general
UI guidelines.
2) Are you suggesting that we emphasize that good UI design is
also related to accessibility?
3) The following statements appear in section 1.1 under
"Ensure that the user interface is accessible":
The general topic of user interface accessibility for
computer software exceeds the scope of this document.
The guidelines do discuss some important user interface
topics such as device-independence, configurability,
and accessible product documentation.
Is this the type of statement you're looking for?
> Some things seem so general that I wonder why the turn up
> in Accessibility Guidelines. For example, should 'general'
> users not be informed when following a link implies a fee?
> That should depend on the depth of the pocket of the user,
> not on accessibility issues, it seems.
We need a "pocket-depth" attribute, I guess!
Such checkpoints exist so that developers will not assume, for
example, that color alone is sufficient to indicate that
following a link will cost money.
I also believe that not all developers would find this as
obvious as you do.
>
> - The document contains a lot about deprecated technology,
> e.g. frames. There should be a comment saying that mentioning
> something does not necessarily mean it's a good feature for
> accessibility (see xxx guidelines), but that things are
> mentionned here nevertheless if they are sufficiently
> popular to justify support.
Frames are not deprecated in HTML 4.0. However, a note under
checkpoint 6.2 about support for deprecated features might
be useful. I propose:
For reasons of backward compatibility, user agents should
to continue to support deprecated features of specifications.
The current guidelines refer to some deprecated language
features that do not necessarily promote accessibility but
are widely deployed.
> - Guideline 9.2: I don't get this. Do you want to say tha
> it is in the currently selected viewport, i.e. that the
> viewport may have to be changed? Or that the point of
> regard has to be changed?
Suppose that the user is tabbing through links and the next
link is outside of the current viewport's contents. When
the focus is moved, the viewport should be scrolled so that
the focus is in the viewport afterwards.
> - 10.1/10.2: I personally feel that showing author-set
> configurations is at least as important as user-set;
> many (not all) users may be able to remember to their
> own settings, while nobody will know author settings.
Ok, I'll add that to comments on issue 112
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#112
> - 10.3: Single-stroke/single-key: Does this include modifiers
> or not? There are in general not enough keys to have one
> (unmodified) for each function.
No, this doesn't include modifiers. The requirement of 10.3 is
not that each functionality be bound to a single key, only
that users be able to activate a functionality with a single
key. For example, the user could select the 20 most important
and configure the user agent for those 20.
We'll discuss this when we discuss issue 134
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#134
> What is a 'self-voicing' browser.
Changed to voice-activated.
> - 10.7: Frequently requested commands: Are these new commands
> that are requested from the software manufacturer? If not,
> maybe better 'frequently used commands'.
Ok.
> - Please separate out each Definition to make it accessible in
> the printed version (or e.g. put a pointer from 'Point of Regards',
> in its correct alphabetical position, to the entry where it's
> discussed).
Ok.
> - Please rewrite the texts in the 'definition' section to read
> more like definitions of terms, or change the title, e.g. to
> Glossary, or background explanations.
I'd rather change the section to "Glossary"
> - On Netscape 4.0, the boxed Guideline titles disappeared when
> printed.
You mean the entire title disappears, or just the box?
Note that we provide PS and PDF versions for better printing.
> Section 1.1: It will also will
Fixed.
> Priority 1 mentions users with disabilities, the other
> priorities don't. Is this on purpose?
No, I'll fix.
> Double-A and Triple-A should also provide the original
> spelling (AA and AAA), to make sure users understand what
> is referred to.
The original spelling is Double-A, not "AA". The WCAG WG
decided not to use "AA" at all for reasons of speech
synthesis, and we adopted their decision.
> Conformance, Form 1: A list of checkpoints that have been
> satisfied and which are considered not applicable.
> Satisfying the checkpoints that are not applicable sounds
> really strange.
Ok.
> Form 2: Link the icon to the ... W3C explanation: It is
> probably a good idea to also provide a link to the list
> of things satisfied/not applicable.
That's my suggestion in issue 136
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#136
> 2.2: Closed closed captions
Fixed.
> Guideline 4: in including -> including
Fixed.
> 4.17: No stylesheets: Does this mean that the default
> stylesheet applies, or what?
Yes. Refer to issue 132.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#132
> Guideline 7: through rendered in -> through rendering in?
Fixed.
> Refer also to guideline 10..: double period, there are
> more of these, but easy to find.
The second period is generated by a script. I'll be more careful.
> Guideline 8: will assist the user understand ->
> will assist the user to understand
Fixed.
> output device-independent: weird grouping/use of space and hyphen
> There are more of these, e.g. user agent-initiated
Is this incorrect? We use "device-independent" and "output device"
so why not "output device-independent"?
> 11.1: but one must be accessible -> but at least one must be...
Yes.
> Sorry, I have a few more points, mostly minor, but I have
> to leave now. Will send them tomorrow.
Thanks again Martin!
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Monday, 6 December 1999 09:35:21 UTC