W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Real Networks initial review of last call UAGL [Fwd: User Agent Accessibility Guidelines - feedback]

From: Ian Jacobs <ij@w3.org>
Date: Sun, 21 Nov 1999 14:54:56 -0500
Message-ID: <38384E10.FEF702C9@w3.org>
To: w3c-wai-ua@w3.org, bridie@real.com, smcadoo@prognet.com, w3c-wai-cg@w3.org
Bridie Saccocio wrote:
> 
> Ian-
> 
> Steve McAdoo (also from our Authoring Tools group) offered up the following initial review of the User Agent Accessibility Guidelines. I'm working on getting some more feedback from other areas of the company.
> 
> Hope you find this information useful in the mean time.
> 
> --Bridie
> 
> >>>>
> Your e-mail's first question was "Do you understand the guidelines and checkpoints, or do they need clarification." My answer is "Yes, I understood them - with a few exceptions scattered here and there (like "alternative equivalents for content", which is explained with examples that themselves probably need explanations - "alt" attribute values in HTML, external long descriptions").
> 
> My more fundamental issue with parts of the spec is a lack of clarity, or explanation of how exceptions are to be determined or ruled on. For example, 1.1 grants exceptions for functionalities that are "inherently bound" to a particular API. Where is that line to be drawn exactly? Or if it's impossible to fully spec that, how does a particular exception case get determined, and by whom? 

Hi Steve,

Section 1.2 gives a short explanation:

<BLOCKQUOTE>
Each checkpoint is intended to be specific enough so that someone 
reviewing a user agent may verify that the checkpoint has been 
satisfied. Note. While the checkpoints have been designed to be
verifiable, some may be difficult to verify without documentation
from vendors about what features and APIs they support.
</BLOCKQUOTE>

The guidelines have to be simultaneously precise enough to be usable
and flexible enough to apply to a variety of cases, future technologies,
etc. This specification does not indicate who draws the line and
who, say in a legal setting, would determine whether a user agent
actually conforms to the intent of the guidelines. I suspect such
issues lie outside the scope of this particular document, but the
issue is real. Jon Gunderson has already raised it with the
WAI Coordination Group (on 5 october). I don't know whether the 
WAI CG has considered the question.

>1.5 requires that developers ensure that "all messages to the user be available through all output device APIs used by the user agent." Is this an absolute? 

I would argue that "yes" that it's an absolute.

> What about progress bars, for example, that visually give an indication of percentage of task completion. Do these absolutely require a text readout equivalent, even in cases where that would make the UI visually unappealing, 

Again, yes.

> or where the progress is generally going to be so fast that an audio readout "onetwthrfofiftysininetyhundred" is going to be meaningless? 

That's an interesting case. It sounds like there are several scenarios
possible:

1) The resource is loading really slowly or is stalled
   and in that case, the percentage information may be more 
   useful than, say, a proprotional progress bar. It's easier for me
   visually to determine progress by watching numbers slowly tick
forward
   than by guessing whether a graphical bar has grown by a pixel.

2) The resource is loading really quickly, in which case, the word
   "Loading" (or loading quickly) would convey the necessary
information.
   If the resource is loading quickly, I don't actually care about it's 
   precise progress, only that it's progressing at a reasonable rate. I
may
   want to return to "percentage mode" if, for example, I pause loading.

The user's requirements are the same whether the information is
conveyed graphically or numerically, and while the graphical
rendering can complement the text rendering, I think the text rendering
can serve all users' needs equally well.

>These "where do you draw the line" questions are probably the type that often come up
> with such guidelines , but seems like even more of a problem with standards having to do with accessibility. Perhaps all that's needed is a statement in the intro re exceptions and how they get determined, but it does seem to be something that needs to be addressed in the spec but isn't - at least not in the first third of the document that I reviewed.

Thanks for the comments, Steve. Perhaps we should augment the
text in 1.2  as follows:

  <BLOCKQUOTE>
  Each checkpoint is intended to be specific enough so that someone 
  reviewing a user agent may verify that the checkpoint has been 
  satisfied. Then question of how reviews are verified lies outside 
  the scope of this document and is likely to be addressed by the
  Web Accessibility Initiative in other resources.
  Note. While the checkpoints have been designed to be
  verifiable, some may be difficult to verify without documentation
  from vendors about what features and APIs they support.
  </BLOCKQUOTE>

 - 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 Sunday, 21 November 1999 14:54:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT