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

Richard Premack wrote:
> 
> Review of "User Agent Accessibility Guidelines 1.0 (UAAG 1.0) last call
> Working Draft-April-2001"
> 
> Prepared by:
> Richard Premack, interNext
> richardp@inter-next.net
> 1-888-576-8932 (USA) 1-727-821-8315 (Int'l)
> 
> The following is in response to an invitation by Jon Gunderson, Chair --
> W3C WAI User Agent
> Working Group to review and provide comment on the "User Agent
> Accessibility Guidelines 1.0" (UAAG 1.0) last call Working
> Draft-April-2001".
> 
> Please accept my sincere apologies for this late submission.  I am honored
> to be invited again to participate in the Last Call Review of the UAAG and
> hope that the information presented here will prove useful in moving this
> draft to an official recommendation in the near future.

Richard,

Thank you for your review of the 9 April 2001 UAAG 1.0 [1],
which is very useful even at this date. Please
see my responses below (preceded by IJ:). Some of my replies
indicate how the UAWG has changed the document up to and
including the 22 June 2001 draft [2] based on other last call
review comments.

I'm really pleased because your comments show that you've
read the document thoroughly. Thank you!

I've snipped out some of your comments to shorten this message.

 - Ian

[1] http://www.w3.org/TR/2001/WD-UAAG10-20010409/
[2] http://www.w3.org/TR/2001/WD-UAAG10-20010622/

-------
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?

Richard's comments and my responses start here:

>1.2 Criteria
>
>Per the instructions for this (Third) Last Call, this review will
>focus primarily on clarifications to UAAG 1.0., rather than
>substantive checkpoint issues which have already been brought to
>the attention of, and considered by, the User Agent Working Group
>(UAWG).

Excellent! <relieved grin>

>2.0 General Comments

[snip]

>In the opinion of this reviewer, this last call document is
>essentially complete, correct and comprehensible and therefore
>suitable (except as noted below) for advancement to the next
>stage of the W3C recommendation process.

>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.

>[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.

>[Guideline 6. Implement standard application programming interfaces.]
>
>The use of the word 'standard' used out of context and without prior
>definition is non-specific and easily misinterpreted. However, a
>satisfactory definition that explains the use of the word standard in
>this context exists in the glossary under "Application Programming
>Interface (API), standard input/output/device API ".
>
>I would therefore recommend a local link to this definition at the
>point where the word appears in the subtitle for Guideline 6 as in:
>
>Implement <a href="#def-api">standard</a> application programming
>interfaces.
>
>... or a similar technique for providing a definition of the term at
>the point of introduction within the document.

IJ: Since the last call draft, we have eliminated the term
"standard API" as well as the need for the term. We have made the
requirements of Guideline 6 more precise. However, the term
"standard" was intentionally left in the Guideline title in the
hopes that it would convey a sense, if the not the details of the
requirements that follow. I don't have a proposal for a better term.

>[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?

>[Checkpoint 10.2]

>The note giving examples of various highlighting mechanisms,
>specifically for speech synthesis output using distinctive voice
>pitches should be made consistent with the description of
>highlighting at the end of the Glossary definition of "Selection,
>current selection" and also within " Properties, values, and
>defaults", i.e., that speech synthesis highlighting and style
>should be implemented using speech prosody, rather than natural
>language-dependent elements such as inflection, pitch, volume,
>etc.

>This was previously addressed as issue #374
>(http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#374)
>
>and resolved:
>

>#374: Definition: Selection, current selection and use of
>inflected speech.
>
>Comment: The definition of selection now reads, instead of
>"inflected speech":
>
>"The selection may also be rendered through changes in speech
>prosody, for example."

IJ: Yes, I agree.

>[Checkpoint 10.4]
>
>See review comment for Checkpoint 10.2 above.

IJ: Ok.

>[Checkpoint 11.4]
>
>Third sentence in the first paragraph contains a double-word typo:
>
>"If the number of physical keys on the keyboard is less than the
>number of functionalities required by by checkpoint 11.5 .... "

IJ: Fixed in the 22 June draft.

>[Guideline 12. Provide accessible product documentation and help.]
>
>First sentence of the first paragraph,

>"User agent documentation is especially important to users with
>disabilities who may not understand a complex graphical user
>interface, who may not be using part of it (e.g., audio cues), or
>may not be using it at all."

>It appears that the use of the phrase "... may not be using part
>of it" is not what was intended as the example audio cues would
>be an item outside of the graphical user interface that would aid
>those not able to use a graphical environment.

>Instead, perhaps the following was intended:
>
>"User agent documentation is especially important to users with
>disabilities who may not understand a complex graphical user
>interface, who may only be using part of it (e.g., audio cues), or may
>not be using it at all."

IJ: I agree that it's confusing to talk about graphical user
interface and audio cues as written. I'll tidy it up.

>[3.5 Checkpoint applicability]
>
>The use of the word "though" instead of the word "if", in the last
>sentence in item #2 may be unintended,
>
>"HTML user agents are not expected to recognize that a nearby
>paragraph is a text equivalent for the image (though not marked up as
>such)."
>
>But rather,
>
>"HTML user agents are not expected to recognize that a nearby
>paragraph is a text equivalent for the image (if not marked up as
>such)."
>
>appears to be what was intended.

IJ: Yes, I agree.

>[3.6 Well-formed conformance claims]
>
>In Condition 1, item #5 (Information about the subject), in the case
>where the user agent may be server-based and the user interface is
>provided by thin-client technology such as a cell phone, PDA, etc.,
>the claim should provide information about the applicable client
>technology.
>
>For example, "Product X (version 2.3) running on MyO/S (version 2.2)
>with Brand-A WAP-proxy agent (version 1.3). Requires Brand-B 6300-W or
>equivalent WAP-enabled client device."
>
>In this case, user agent functionality and therefore the subject(s) of
>the claim may actually be split between client and server platforms.
>
>Note: Above product names and models are fictional and used for
>example only.

IJ: In my opinion, that's just one example that is already
covered by the conformance model: it doesn't really matter to us
where the components that are in the subject of the claim
reside. For instance, the documentation to satisfy Guideline 12
may be on the Web or on a CD. I would note that for some of the
requirements of the document, server-based functionalities are
exempted explicitly when they cannot be controlled by the user
agent (another way of saying that they are not part of the
claim).

We could include your example (with fictional product names and
all) to illustrate the case of a distributed user agent. I note
that this is not really our target user agent, however.

>[3.7 Validity of a claim]
>
>Under subtitle "Requirements for content, user agent features, or
>both", last sentence of the subsection contains a double-word typo:
>
>"This includes not only the requirements that directly refer to to
>user control, .... "

IJ: Fixed/changed in the 22 June draft.

>In the note, exactly what is meant by digital rights management ? A
>definition or other clarification would be helpful.

IJ: I can steal this text from the W3C announcement [3] of the
Digital Rights Management workshop earlier this year:

 "Digital Rights Management (DRM) refers to techniques for
 describing and perhaps enforcing copyrights associated with Web
 resources"

[3] http://www.w3.org/2000/11/w3c-drm-cfp

>[4. Glossary]
>
>Assistive technology
>
>First sentence in item #2 contains a superfluous word "a":
>
>"provides services beyond those offered by the host user agents to
>meet the requirements of a users with disabilities."

IJ: Yes.

>Document character set
>
>First sentence contains inappropriate use of the word "an" before a
>word beginning with a consonant:
>
>"A document character set (an concept taken from SGML) is a sequence
>of abstract characters that may appear in Web content represented in a
>particular format (such as HTML, XML, etc.)."

IJ: Yes.

>Highlight
>
>See review comment for Checkpoint 10.2 above.

IJ: Ok.

>Visual track
>
>Second sentence contains inappropriate use of the word "an" before a
>word beginning with a consonant:
>
>"An visual track is a visual object that is intended as a whole or
>partial presentation.

IJ: Yes. I even found a few other instances of "an visual" based
on your comment. Heh heh!

>Views, viewports
>
>A scrolling feature is called for when content viewed through a window
>or viewport exceeds the dimensions of the window or viewport itself.
>The scroll bar or "elevator" as it is sometimes referred to may then
>be used to modify the point of regard within the viewport to the
>desired content.
>
>The explanation of viewport operation provided by the last sentence of
>the first paragraph reverses this definition:
>
>"When the dimensions (spatial or temporal) of a viewport exceed the
>dimensions of rendered content, the viewport includes mechanisms such
>as scroll bars and advance and rewind functionalities to provide
>access to the content."
>
>Perhaps what was intended was:
>
>"When the dimensions (spatial or temporal) of the rendered content
>exceed the dimensions of the viewport, the viewport includes
>mechanisms such as scroll bars and advance and rewind functionalities
>to provide access to the content within the viewport."

IJ: Yes, you are correct. There have been other edits to the text
since then, and I will incorporate your change into the new text.


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

Received on Wednesday, 27 June 2001 01:27:46 UTC