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-October-2000"

Hi Richard,

Thank you very much for reviewing the documents. I have some
comments below on your questions. I've incorporated your editorial
suggestions. Issues you have raised will appear in our issues list:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html

 _ Ian


> 2.0 General Comments
> 
> In the opinion of this reviewer, this last call document is noticeably
> improved over that which was presented for last call review a year ago
> (User Agent Accessibility Guidelines 1.0 - W3C Working
> Draft-November-1999).  Specifically, the abstract and introduction of
> the current document provide clearer, more direct statements of the
> purpose of the User Agent Accessibility Guidelines (UAAG), it's
> benefits and impact on User Agent developers and their end-users.

Thanks for the support!
 
> The organization of the document is also improved in terms of logical
> flow of topics and simplified section titles. The sections themselves,
> including individual checkpoints are well-written and contain a
> surprisingly small number of typographical errors give the amount and
> complexity of information being presented. Hopefully, the same can be
> said for the number of typos inevitably present in this review.
> 
> 3.0 Specific Comments
> 
> [Checkpoint 2.5]
> 
> The note for the checkpoint states that when the content author does
> not provide text equivalents for content "? the user agent is required
> by this document to generate repair text.". However, the definition
> for "repair content, repair text" indicates that "This document does
> not require user agents to include repair content in the document
> object." Presumably the difference between the definition of Repair
> Content vs. Repair Text might explain these seemingly contradictory
> statements, but isn't Repair Text a type of, i.e. a subset of, Repair
> Content? In any case, some additional clarification might prove
> helpful.

The key term here is "document object". If the repair content is
included in the document object, then it will be available through
the DOM. If the repair content is "just rendered" (or for any
reason not in the DOM) then it will not be available through the
DOM (to assistive technologies). This document does not require
that generated repair content (including repair text) appear
in the DOM.
 
> [Guideline 3]
> 
> Along these lines, it is noteworthy to mention that repetitive and
> redundant content can reduce accessibility to a great extent. Consider
> the web page with multiple (sometimes 3 or more) redundant navigation
> bars (image maps, etc.) that must be rendered and played (in the case
> of a speech-synthesizer) each time the viewpoint is opened. This is at
> least as significant an impact on accessibility as blinking text,
> which has merited a Priority 1 ranking.

This sounds like an authoring (read: WCAG) problem. How does
the user agent know that content A is redundant to content B
(and furthermore that the redundancy isn't for the express
purpose of promoting accessibility)?
 
> [Checkpoint 3.5]
> 
> Just a reminder that allowing the user to "configure the user agent
> not to execute scripts or applets" in many cases will result in no
> content being rendered, unless the content author has provided
> equivalent accessible content, which unfortunately is currently an
> uncommon situation.

Thus the requirement that the user agent alert the user that scripts
are available but not being executed. This should help the user guess
why there is no content available. I propose to add this scenario
to the techniques document as another piece of rationale.
 
> [Checkpoints 3.6 and 3.7]
> 
> These checkpoints both discuss author-specified redirects (supported
> by a HTML META element with http-equiv="refresh"). However the
> "Techniques for checkpoint 3.6" refer the reader to information on the
> HTTP 1.1 specification [RFC2616] where there is no discussion of
> author-specified redirects, using HTML "refresh". This, even though
> checkpoint 3.6 clearly states that a "?. client-side redirect (i.e.,
> one initiated by the user agent, not the server." is being
> considered. The "Techniques for checkpoint 3.7" appears to include the
> information applicable to both checkpoints.

Good point. I think the idea is to point people to information
about doing server-side redirects *instead of* client-side
redirects. I'll clarify that that this note is really for authors.
 
> [Checkpoint 3.8]
> 
> The ability to allow the user to configure the user agent not to
> render images seems worthy of a Priority 1 ranking. This is a key
> functionality, alluded to in 1.2 and appropriately identified in
> Guideline 2 has having an impact on rendering speed, thereby reducing
> overall accessibility.

I'll add this to the issues list. Please also refer to
previous discussions on this topic (issue 264):
   http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#264
 
> [Checkpoint 4.13]
> 
> Even though the reader is referred to checkpoint 4.11, it might be
> more instructive to mention that this checkpoint "is a special case"
> of checkpoint 4.11.

I'm not sure it's a special case since synth speech is not
necessarily "audio source(s) synchronized to play simultaneously".
 
> [Checkpoint 4.14]
> 
> It might be useful to refer the reader to section 3.3 "Checkpoint
> applicability" in the circumstance that the speech synthesizer does
> not support changing the voice characteristics identified
> (e.g. gender, pitch, etc.). Specifically, the last exclusionary rule
> of checkpoint applicability "The checkpoint requires control of
> content properties (e.g., video or animation rate) that the subject
> cannot control (e.g., the format does not allow it) or does not
> recognize (e.g., because the property is controlled by a script in a
> manner that the subject cannot recognize)" would apply in this case.
> 
> For instance, the checkpoint might be rewritten as:
> 
>    "Allow the user to configure synthesized voice gender, pitch, pitch
>    range, stress, richness, and control of spelling, punctuation, and
>    number processing according to the full range of speech
>    characteristics and corresponding values offered by the speech
>    synthesizer, except as exempted by section 3.3 "Checkpoint
>    applicability".

We will discuss this as part of issue 357
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#357
 
> [Checkpoints 4.16 and 4.17]
> 
> The note for these Priority 1 checkpoints refers the user to
> checkpoint 4.14 for information on control of speech output as it
> relates to highlighting. Should it be inferred that highlighting of
> speech output is a P1 or P2 user interface characteristic? 

Yes.

> I would suggest that it is P2 since the absence of speech output highlighting
> does not meet the standard set for Priority 1 checkpoints. Namely,
> that the checkpoint must be satisfied by user agents, otherwise one or
> more groups of users with disabilities will find it impossible to
> access the Web.

Can you explain why this is? If the focus or selection is not
highlighted
somehow through speech, how does the user know what content is
focused or selected?
 
> [Checkpoint 4.20]
> 
> Some brief examples might help illustrate the difference between this
> checkpoint and Checkpoint 4.18, both checkpoints being concerned
> primarily with automatic or manual (via explicit user request) opening
> of a new viewport. Is checkpoint 4.18 a special case of 4.20 ?

Not exactly, though they are related:

 4.18 is about focus changes (which may be disorienting)
 4.20 is about viewport changes (which may be disoriented for other
reasons,
   including the sheer number of viewports, or one viewport hiding
another).

Often, when a viewport opens, the focus shifts automatically to it.
That's
what 4.18 is meant to cover. 
 
> [Checkpoint 6.1]
> 
> Unless I have misinterpreted it's meaning, this Priority 1 checkpoint
> requires all accessibility features of all implemented specifications
> to be implemented such that they comply with all requirements of the
> Web Content Accessibility Guidelines.

Yes.

> This suggests Triple-A
> compliance on the web content (server) side that must be met with the
> highest level of accessibility by the user agent.

Yes.

> Are we sure we want
> to make this extreme level of compliance mandatory? Returning to the
> definition of Priority 1, do we truly believe that unless all
> accessibility features and all requirements imposed by the WCAG are
> met, one or more groups of users with disabilities will find it
> impossible to access the Web? It seems that lesser levels of
> compliance (Single-A) should be mandated (P1), while higher levels
> (Double and Triple-A) recommended (P2 and P3).

This issue was raised in the first last call (issue 111).
   http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#111

At their 10 December 1999 face-to-face meeting, the 
Working Group decided to leave this as a Priority 1 checkpoint
for a very specific purpose: to give authors the possiblity
of using "P3" WCAG requirements. The WG felt quite strongly
that if user agent developers don't take the lead in implementing
features that promote accessibility, then having P3 requirements
in WCAG will serve no purpose.
  
  http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-111
 
> [Guideline 7]
> 
> This section describes three (3) separate modes of content navigation.
> Sequential in which content is advanced line by line with link choices
> made active as they appear (and deactivated as they disappear) within
> the context of other content on the page; Direct in which content is
> bypassed by specifying some selection criteria that if met directs the
> focus of the viewport directly to the desired content or link; and
> finally Structured wherein important structural items (headers,
> titles, etc) are presented without the corresponding intervening
> non-structural content.
> 
> In point of fact, there is actually a fourth mode possible, which
> could be described as "Oriented-Direct" in which content and links are
> rendered sequentially in-context, but links are available for direct
> access to web resources at any time, (i.e. during, after) even
> immediately prior to content rendering. This navigation mode has the
> added benefits of context, speed and complete content availability,
> not offered by the other three modes taken on an individual basis.

I'm not sure I understand yet.
Can you please provide us some implementation examples of this?
 
> 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, "content only" should be added to the
> description of navigating mechanisms just prior to the checkpoints for
> this section:
> 
>    "User agents should allow users to configure navigation mechanisms
>    (e.g., to allow navigation of links only, or links and headings,
>    content only, or tables and forms, etc.)."

I'm not sure what "content only" means. Aren't links part of content?
Or do you mean a kind of "read-only" presentation where the user
cannot interact with the document? That seems un-Web-like to me....
 
> [Checkpoint 10.5]
> 
> This Priority 2 checkpoint recommends documenting changes in user
> agent and/or assistive technology software, as a result of software
> upgrades, that affect accessibility. This seems to be at least as
> significant as documenting accessibility features (checkpoint 10.2)
> which has been given a Priority 1 ranking.
> 
> Undisclosed changes in accessibility feature availability and or
> operation as a result of software upgrades can be disorienting to a
> user that has become accustom to certain feature behavior. For this
> reason, I would recommend raising this checkpoint to Priority 1
> status.

I'll add to issues list.
 
> [4. Glossary]
> 
> Equivalent (for content)
> 
> In the description for this term it is stated that "If the image is
> part of a link and understanding the image is crucial to guessing the
> link target, then the equivalent must also give users an idea of the
> link target. Thus, an equivalent is provided to fulfill the same
> function as the equivalency target.". While true, it should be
> remembered, and possibly noted in the definition since this document
> applies to user agents that only the content author can determine
> absolutely the equivalent for a given equivalency target.

Agreed. I think that the definition will probably evolve due
to issue #358:
   http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#358
 
> To take the "full moon" example found within this definition:
> 
> If an image of a full moon exists in the content, there is no method,
> short of complex image analysis, for a user-agent to determine on it's
> own that the image should be described as a "full moon", "harvest
> moon" or "white disk".
> 
> Selection, current selection
> 
> The suggestion that selected content should be rendered as "inflected
> speech" by a speech synthesis system is somewhat questionable. Speech
> inflection occurs many times within normal speech and in addition,
> what constitutes inflection is neither speaker nor listener
> independent. In other words, what one listener feels is inflected
> speech may seem normal to another listener and vice-versa. There may
> be no reliable method of conveying selected content when human speech
> is involved, other than possibly volume changes or marker tones, the
> latter being fairly common.

Ok.

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

Received on Tuesday, 14 November 2000 21:17:47 UTC