Re: Reviewer Comments: Last Call Version of the UAAG 1.0

Look for IJ2: below.


Richard Premack (RP) wrote:

> -------
> Summary of more-than-simply-editorial questions to take to the
> Working Group:
> -------
> 
>  - Should we remove speech output from the list of limitations
>    to the document since there are a number of requirements?

[snip]

> >3.0 Specific Comments
> >
> >[1.1 Relationship to WAI accessibility guidelines]
> >
> >Last sentence in the first paragraph discussing UAAG 1.0 as one
> >of a series of accessibility guidelines published by the WAI:
> >
> >"These agents intersect and complement each other as follows":
> >
> >It appears that the 'agents' is not what was intended as this
> >paragraph discusses documentation not software. Instead, perhaps the
> >following would be appropriate:
> >
> >"These documents, whether in the form of guidelines or formal
> >specifications, intersect and complement each other as follows:"
> 
> IJ: The word agent was intentional, but not a good
> choice. "Agent" here meant "actors in the accessibility drama":
> authors, developers, spec writers. I'll find better wording.
> 
> RP: Might I suggest the word *stakeholders* to mean "actors in the
> accessibility drama"?  I see that usage quite a bit.

IJ2: Yes, I like that.
 
> >[1.3 Known limitations of this document]
> >
> >
> >Under the enumeration of known limitations, specifically
> >Synthesized speech, it is stated that there are few checkpoints
> >for synthesized speech output. There are in fact, five (5)
> >checkpoints (4.11 through 4.15) addressing synthesized speech
> >which is one less that the number of checkpoints for Guideline 5
> >which concerns the user interface (a major component) and one
> >more than the number of checkpoints for Guideline 7 which
> >concerns the operating environment. In the opinion of this
> >reviewer, and as a developer of user agents that utilize
> >synthesized speech output, there is sufficient treatment of this
> >subject to merit removal of the limitation caveat.
> 
> IJ: Ok, let's ask the UAWG.
> 
> RP: Good, because I just don't see the UAAG's treatment of Speech output
> issues to be anything to be apologizing for, if you know what I mean.
> Unless the limitation notice is about Speech input, which I would
> agree has not been considered (or at least discussed in the document).

IJ2: That, at least, should be clarified.
 
> >[Guideline 6. Implement standard application programming interfaces.]
> >
[snip]

> RP: Actually, while initially I always instinctively recoil when hearing
> the term 'standard' because of it's ambiguity (unless we're talking actual
> W3C standards).  -- We've all heard the Microsoft joke about declaring
> darkness a standard instead of changing the light bulb.  However, I thought
> the glossary definition for API covered it very well and was quite
> comfortable with it's use if the definition could be tied to the term
> itself using hypertext or some other mechanism.  Now that it has been
> eliminated for the most part, may I suggest "interoperable" as an
> appropriate substitute which happens also, to be used in the Guideline 6
> opening paragraph.  This was going to be my first suggestion until I
> happened upon the glossary definition.

IJ2: I also like that suggestion.
 
> >[Guideline 9. Provide navigation mechanisms.]
> >
> >While this might be considered a rehash of a prior review point, I
> >nevertheless feel it necessary to once again mention that in some
> >cases, it may be desirable to navigate content without being prompted
> >for the selection of active links, in order to quickly examine a page.
> >
> >In support of this "quick review" capability, an additional navigating
> >mode, "non-links only" could be added to the description of navigating
> >mechanisms just prior to the checkpoints for this section as in:
> >
> >"User agents should allow users to configure navigation mechanisms
> >(e.g., to allow navigation of links only, or links and headings,
> >non-links only, or tables and forms, etc.)."
> >
> >This has been characterized as "un-Web-like" but I can assure you in
> >practice it becomes a valuable mode to scan a web page when the page
> >is being rendered using speech synthesis and contains many (often
> >redundant) links. The prompting associated with the point of regard
> >moving serially through numerous link selections can interrupt the
> >natural flow of the document and therefore adversely impact
> >comprehension.
> 
> IJ: That is exactly the intention of checkpoint 9.9 (in the 22
> June draft):
> 
> <BLOCKQUOTE>
> 9.9 Structured navigation. (P2)
> 
>   1.Allow the user to navigate efficiently to and among important
>   structural elements.
> 
>   2.Allow forward and backward sequential navigation to important
>   structural elements.
> </BLOCKQUOTE>
> 
> Does this satisfy your comment?
> 
> RP: Not quite, unfortunately, because the determination of what is an
> important element is determined by which tags of the markup language are
> being used which assumes the author will know enough to use these tags
> and/or that the user agent can be configured (dynamically) as to which
> elements are "important".

IJ2: Yes, this is exactly our model - the user agent is, with few
exceptions,
not required to repair broken markup. We ask authors to use markup
according
to specification (not necessarily coding by hand, but using authoring
tools
that save and use markup according to specification).
 
> One would think that an author would at a minimum, frame important text
> within a paragraph tag, but you can never be certain this will be the case.
>  The only thing we are guaranteed, worst case, is that the 'important' text
> will
> be somewhere between <HTML> and </HTML>.  For this reason, I just feel
> there needs to be a mode where links are simply turned off and all text not
> related to navigating elsewhere is spoken.  I use this mode quite often
> when I first 'visit' a site using Phone2Web, our product.  For instance, at
> Yahoo, I can usually get hear what the page is all about in a fraction of
> the time it would take me if I had to be prompted for every link in their
> huge navigation bar.

IJ2: At one point, the UAAG 1.0 included a checkpoint about turning
off navigation bars. And HTML 4.01 was modified to allow authors to
use the MAP element for non-graphical navigation mechanisms, so that
user agents could recognize them and turn them off. 

Ultimately, instead of keeping this requirement, we included the
more generic structured navigation requirement. There were too many
special case requirements that are useful, but would have bloated
the document. These included: navigation bar control, navigation of
table cells, navigation from table to table, etc. 

The structured navigation required is expected to allow users to
skip navigation blocks as you have described in your example. However,
UAAG 1.0
proposes a generic mechanism for navigation of "important elements", not
just
links, or blocks of links, or tables, etc.

I have snipped the rest of the comments as we seem to be
in agreement!

Thanks again, Richard, and thank you for the support!

 - Ian
 
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Cell:                    +1 917 450-8783

Received on Monday, 2 July 2001 23:42:27 UTC