- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 01 Dec 1999 09:17:29 -0500
- To: John Gardner <john.gardner@orst.edu>
- CC: w3c-wai-ua@w3.org
John Gardner wrote:
>
> Sorry about being tardy with my review. I was traveling for most of the
> review period. I have a few comments to add to the extensive on-list
> discussions by other reviewers and the members of the UA working group. I
> have only skimmed many of these an apologize if I plow some of the ground
> again.
No problem, here we go!
> Comment 1. Word usage.
> 1a. There is no definite "right" answer to whether braille is capitalized.
> My strong preference is simplicity, so I do not capitalize it.
At the 24 November teleconf [1] we decided to go with "Braille" since
more
people favored that spelling and there were no objections.
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0426.html
> 1b. Braille is a representation of text that depends on the language being
> represented. It is certainly not a natural language.
Right.
> 1c. Braille is tactile, not haptic.
We had some discussion of this as well on 24 November and it
was minuted that Braille is haptic. We'll have to review that
(or just delete the term from the document).
> 1d. My preference on politically correct language is to avoid offending
> people unnecessarily but to keep it simple. I personally prefer to be
> called a blind person than a person with blindness or a person who is
> visually challenged. The terms physical disability, visual disability,
> hearing disability, and cognitive disability are common well-understood
> relatively inoffensive terms.
Those four sound fine to me, but it may become tedious to use only
those.
> I suggest that this document not split hairs
> over technical correctness of terminology or use ridiculously contorted
> language.
It would be a useful exercise for the Working Group to choose
appropriate terms and then the editors will ensure their application.
> Comment 2. The Committee question about Checkpoints 10.1 and 10.2. My
> initial reaction to these checkpoints is that they don't really make much
> sense. Perhaps they would if I had followed the discussion that led to
> them, but I didn't, and most readers of the guidelines will be similarly
> unenlightened. 10.1 gives priority 1 to provision of access to user-set
> input configurations whereas 10.2 gives priority 2 access to author-set
> configurations. 10.1 is apparently targeted toward specialty browsers,
> screen readers, etc. whereas 10.2 must be taken into account by all user
> agents that do not also control content input.
The WG split one checkpoint into two because some members of the WG
felt it was more important for user agents to document configurations
they allow than to document configurations specified by the author.
The split did not have to do with different types of user agents.
> 10.1 seems so unnecessary
> as to be frivolous (i.e. we don't find it necessary to require a visual
> browser to support the video monitor). On the other hand, an author might
> specify an access key that is critical to access, and it is critical that I
> know what it is. Frankly I am unfamiliar with the use of this authoring
> technique and couldn't imagine an author specifying input configurations
> without telling the reader, so I would think this is more of a authoring
> issue than a UA issue. Without some enlightenment as to what alligator I
> am overlooking, my recommendation is to put these into a single checkpoint
> and make it priority 2.
> It certainly doesn't make sense to make 10.1
> priority 1 and 10.3 priority 2, does it?
I'll raise that as an issue with the WG. Refer to issue 133
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#133
> On the subject of 10.3, I strongly urge that the single-controls be
> user-selectable. Chills run down my spine when I think of trying to use a
> user agent with a zillion dedicated keystroke and/or voice commands that
> are hard-wired into the application. Add the sentence "The controls must
> be user-selectable."
This proposal added as issue 134
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#134
> Comment 3. The committee question about checkpoint 6.1.
> I do not really understand "relative priority".
The term does not yet appear in the document, but is used in
the Authoring Tool Guidelines [2]:
<BLOCKQUOTE>
Some checkpoints that refer to generating, authoring,
or checking Web content have multiple priorities.
The priority is dependent on the priority in the Web Content
Accessibility Guidelines [WAI-WEBCONTENT].
</BLOCKQUOTE>
[2] http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026/#priorities
> I do understand that in
> certain circumstances both authors and user agents must violate a
> checkpoint in order to provide excellent access.
I'm not sure I understand (or agree) with this comment. I think below
you explore this more.
> This is inevitable,
> because no set of rules can cover all situations even if the authors of
> these guidelines had crystal balls. However my strong preference would not
> be for a nebulous concept like "relative priority" but for a simple
> acknowledgement (as suggested by Eric Hansen at the end of his review) that
> there are circumstances where WAI rules cannot fully apply.
Relative priority would have a specific meaning:
"It is Priority 1 to implement the checkpoint for
content features that are a Priority 1 requirement
in [WAI-WEBCONTENT]."
And so forth for Priority 2 and Priority 3.
> That's a long-winded way of saying 6.1 is fine as written.
Perhaps with the clarification above you have a different opinion.
> Comment 4. I am confused about the applicability of many checkpoints to
> specific applications. For example, checkpoints 7.1-7.3 are (I believe)
> clearly inapplicable to Netscape, IE, and other general purpose visual
> browsers.
7.1: Allow the user to navigate viewports (including frames).
This is very pertinent to graphical desktop browsers and is possible
today in Opera and Navigator at least.
7.2: For user agents that offer a browsing history mechanism,
when the user returns to a previous view, restore the
point of regard in the viewport.
This is already done by browsers today.
7.3: Allow the user to navigate just among cells of a table
(notably left and right within a row and up and down within a
column).
This was initially for assistive technologies, then rephrased to
include graphical desktop browsers. It is, admittedly, more vague
as a result.
> So they do not enter into their ratings. I believe that 7.6-7.8
> are applicable, but I can also understand how a software engineer might
> conclude that they are not.
7.6: Allow the user to search for rendered text content,
including alternative text content.
Browsers I am familiar with already do this, though perhaps
not for alt content.
7.7: Allow the user to navigate according to structure.
This is not done much today I believe.
7.8 Allow the user to configure structured navigation
This is not done much either.
> (If the search, etc. functionality is not
> available to any user then it is just as accessible to people with and
> without disabilities and therefore within the stated UA guidelines, right?)
> This kind of confusion may be inevitable for "one size fits all"
> guidelines. At one time some checkpoints noted that they were specifically
> applicable to dependent user agents, but that language has apparently been
> dropped.
Yes.
> The result may be that the guidelines are more elegant, but they
> are also less clear to me.
We have had other comments that some of the checkpoints that were
generalized to fit more user agents have lost their zing, including
7.3 and 8.2 (both about tables).
> Comment 5. It is not at all clear to me that it is necessary to satisfy
> each checkpoint in order for a user agent to provide excellent usability to
> people with disabilities.
That is likely true: you could satisfy all but one of the Priority 1
checkpoints and you would be close to being a Level A user agent.
But you wouldn't be Level A. The Working Group decided for a number
of reasons (and after many discussions, refer to summary [3]) to
maintain
three discrete conformance levels.
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0433.html
> For example, guideline 5 and most of its
> checkpoints could probably be violated by an audio-visual browser that
> could nonetheless be more usable than most that meet each checkpoint.
Interesting question: what if you built a really really accessible
tool that did not communicate any information to other tools?
I suspect that the answer would still be that the tool, while useful,
would not be accessible to those who needed to tailor the information
to their particular needs, output devices, etc.
> In
> fact I strongly suspect that it might be actually _NECESSARY_ to violate
> some checkpoints to make an excellent universally usable web agent. These
> guidelines should certainly not have the effect of preventing development
> of innovative universally accessible user agents.
The should not only prevent it, they should (I hope) promote the
creation
of such user agents.
> Therefore I propose that the qualification for a AAA rating be expanded. A
> user agent that meets all functionality described in the guidelines but,
> for whatever reason does not fulfill each checkpoint, should be eligible
> for a AAA rating.
Please expand on this. What would it men to meet the functionality
but not fulfill the checkpoint? The checkpoints have been designed
precisely to capture the functionalities required for accessibility.
How are you separating the dancer from the dance, as it were?
> This flexibility is crucial, since it seems all but
> inevitable that WAI guidelines will become law for state and federal
> agencies. If so then mindless bureaucrats
Ouch!
> can (and almost certainly will)
> use an application's WAI rating as a purchasing yardstick.
Thank you John,
- 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 Wednesday, 1 December 1999 09:17:56 UTC