[Review, Part II] Tantek Çelik / Ian Jacobs comments on 9 April 2001 UAAG 1.0

Hello,

This is the second of three emails that are the result of a review by
Tantek Çelik of the 9 April 2001 (last call) draft of UAAG 1.0. [1].
This mail proposes minor clarifications to the document.

 - Ian

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

================================
1) Section 1.3 Known limitations
================================

Suggest adding this type of Note after the list of limitations:

 "Note: While UAAG 1.0 does not address these issues, they are
 important accessibility issues. The UAWG may address them in a
 future version of the UAAG. The UAWG encourages developers to
 provide innovative solutions to these issues as well as those
 addressed by UAAG 1.0."

Tantek and I also discussed issues of compatibility between
versions of UAAG. I do not believe that the UAWG had addressed
the question of whether it plans to "guarantee" that (potential)
future versions of UAAG will remain compatible with UAAG 1.0,
namely that meeting the requirements of UAAG 2.0 will not
invalidate conformance to UAAG 1.0. I don't believe that the UAWG
can make any such statement at this time, though I agree we
should think about this issue. We might add a note to the
limitations section saying that forward compatibility is not
addressed by this document.

================================
2) Section 2. The guidelines.
================================

Since talking to developers and W3C Working Groups, it has become
apparent to me that it is sometimes challenging to "instantiate"
our fairly abstract requirements for specific formats or
software. The Techniques document seems to help a lot (and I look
forward to providing additional help in the form of more
examples, profiles, test suite examples, etc.). However, I think
the following type of statement might be useful to give readers a
heads-up about what is expected when they read the document:

 <CURRENT>
 Each checkpoint is intended to express one or more minimal
 requirements clearly, so that someone evaluating a user agent may
 verify that it satisfies the requirements. User agent developers
 are encouraged surpass the minimal requirements expressed by the
 checkpoints. Indeed, for some requirements, it is expected that
 developers will find it easier or less costly to implement a
 solution that is more general than one that would only satisfy
 the minimal requirements of a checkpoint. Both this document and
 "Techniques for User Agent Accessibility Guidelines 1.0"
 [UAAG10-TECHS] suggest techniques to help user agent developers
 meet or surpass the minimal requirements. Note: In some cases,
 though the requirement of a checkpoint may be clear, without
 documentation from vendors (e.g., about implemented APIs), it may
 be difficult to verify that the subject of a conformance claim
 has satisfied the requirement.  Some checkpoints (e.g., those
 requiring developers to follow conventions or implement
 specifications defined outside this document) are inherently more
 subject to interpretation than others.
 </CURRENT>

 <NEW> 
 Each checkpoint expresses one or more minimal
 requirements. However, the checkpoints are not technology
 specific. In fact, they have been designed to make sense for a
 variety of existing and future technologies. As a result,
 developers and other readers must think about how the abstract
 requirements apply in specific contexts (e.g., for
 HTML or for SVG, in this or that operating environment, etc.).
 "Techniques for User Agent Accessibility Guidelines 1.0"
 [UAAG10-TECHS] provides technology-specific information that is
 intended to help developers understand how to apply the
 checkpoints in different contexts (and to understand when the
 checkpoints might not apply).

 User agent developers are encouraged surpass the minimal
 requirements expressed by the checkpoints and to address
 accessibility issues not covered by this document. For instance,
 while some checkpoints make requirements for "content only",
 many of those requirements make sense for the user interface as
 well (e.g., allow the user to render blinking text as motionless
 text).

 User agent developers are encouraged to satisfy the requirements
 of this document by adopting "universal design" solutions:
 solutions that improve the user agent for all users and
 simultaneously improve accessibility. In some cases, it is
 expected that universal design solutions will be easier to
 implement or less costly than solutions that merely satisfy the
 minimal requirements. For instance, a navigable structure 
 view of content that allows users to query elements for their
 properties is likely to benefit all users and may be used
 to satisfy a number of requirements of this document.

 Note: In some cases, though the requirement of a checkpoint may
 be clear, without documentation from vendors (e.g., about
 implemented APIs), it may be difficult to verify that the
 subject of a conformance claim has satisfied the requirement.
 Some checkpoints (e.g., those requiring developers to follow
 conventions or implement specifications defined outside this
 document) are inherently more subject to interpretation than
 others.  
 </NEW>

================================
3) Checkpoint 2.4: "Meta refresh" is covered by this checkpoint.
================================

In HTML, the author can create pages that refresh automatically
after a time interval ("META refresh"). This type of content
would be covered by the requirements of checkpoint 2.4. However,
META refresh is also addressed specifically by checkpoint 3.5.
The good news is that 3.5 doesn't seem to be inconsistent with
2.4. The META refresh case should be called out in 2.4, and
possibly added a cross-reference to 3.5.

================================
4) Checkpoint 2.8.: Clarify usage of "empty string". 
================================

Tantek asked us to clarify that a string of three spaces (or any
number of spaces) does not qualify as an empty string.

================================
5) Checkpoint 3.5: Clarify that only about 
   client-side initiated action.
================================

<OLD 3.5>
 ...whenever fresh content is available...
</OLD 3.5>

<NEW 3.5>
 ...prior to any refresh initiated by the user agent...
</NEW 3.5>

Comments: 

 - The old version suggests that the user agent has to query the
 server to find out if new content is available. The checkpoint
 is only about client-initiated refreshes.

 - It might also be useful to change the word "schedule" to "rate".

================================
6) Checkpoint 3.6: Clarify that part about instantaneous 
   redirects is what is encoded in format.
================================

<OLD 3.6>
...for client-side redirects that occur instantaneously...
</OLD 3.6>

<NEW 3.6>
...for client-side redirects specified to occur instantaneously...
</NEW 3.6>

Comment: Similarly, change "there is no delay" to "there is no
specified delay" in the following parenthetical.

================================
7) Checkpoint 4.5: Technique
================================

Add an example to the Techniques about a streaming media
format. Consider two cases for the same format: 

  a) a real-time presentation where some of the requirements
  (e.g., fast advance) might not be applicable.

  b) the same presentation fully available, where the
   fast advance requirement would be applicable.

================================
8) Checkpoint 8.2: Clarify that the checkpoint is not 
   about WCAG 1.0 Level Triple-A conformance
================================

The checkpoint currently reads "specifications that enable the
creation of content that conforms to WCAG 1.0 at any conformance
level". This might be read as "that conforms at level Triple-A".

I suggest changing this to:

<NEW>
Use and conform to either (1) W3C Recommendations when they are
available and appropriate for a task, or (2) non-W3C
specifications that enable the creation of content that conforms
level A or better to the Web Content Accessibility 
Guidelines 1.0 [WCAG10].
</NEW>

================================
9) Checkpoint 9.3: Clarify that a global history is not required
================================

This checkpoint talks about a per-viewport history. MAC IE
apparently has a "global history" as well, and this checkpoint is
not about requirements on a global history common to all
viewports. I suggest adding this to the Techniques document as
further clarification.

================================
10) Checkpoint 10.9: Editorial
================================

The phrase "Indicate the relative position of the viewport in
rendered content" sounds like the indication has to be in
rendered content.

<NEW 10.9>
Indicate the relative position in rendered content of the
viewport (e.g., the proportion of an audio or video clip that has
been played, the proportion of a Web page that has been viewed,
etc.).
</NEW 10.9>

================================
11) Checkpoint 11.3: Operating environment technique
================================

Indicate in the Techniques document that a global facility at the
operating environment level would be one way to satisfy this
checkpoint.

================================
12) Checkpoint 11.6: Not a multi-user requirement
================================

Clarify in the Note after the checkpoint that "allow users to
choose from available profiles" does not mean that the user agent
must have multi-user support.

<OLD 11.6>
Allow users to choose from among available profiles or no profile
(i.e., the user agent default settings). 
</OLD 11.6>

<NEW>
Allow the user to choose from among available profiles or no profile
(i.e., the user agent default settings). 
</NEW>

Comments:

 - It's probably a good idea to state in a Note that the user
 agent is not required to provide access to other users'
 profiles, only multiple profiles for the same user.

 - This is the only checkpoint that uses the plural "users" in
 the checkpoint itself. It might be worthwhile stating somewhere
 in the document that the user agent is only expected to be a
 single-user user agent.

================================
13) Section 3.7, use of op. env. features as part of conformance
================================

Clarify that when the UA adopts an operating-environment
qsolution, that the operating environment controls may be used for
that solution. For instance, the UA is not required to implement
its own "color picker" to satisfy checkpoints 4.3, 10.2, etc.

=======================================================
14) Version information in a conformance claim.
=======================================================

Instead of requiring only specific version information (of a
product or operating environment), the claimant may wish to
specify a range of versions (e.g., "version 4.x", or "any version
after v 8.1").

--------
Proposal
--------

Allow ranges of versions, not just single versions.

=======================================================
15) Condition 3 of well-formed claim: Must it be on the Web?
=======================================================

Condition 3 reads:

  "If the claim is on the Web, it must conform to the "Web
  Content Accessibility Guidelines 1.0" [WCAG10], level A."

However, documentation that conforms to WCAG 1.0 might be
available on a CD-ROM.

--------
Proposal
--------

<NEW CONDITION 3>
"At least one version of the claim must conform to the "Web
Content Accessibility Guidelines 1.0" [WCAG10], level A."
</NEW CONDITION 3>

Comment: 

 - We originally added the "on the Web" part to allow for claims
 in paper documentation, for example. But I think that we should
 go further and require at least one WCAG-conformance claim. 

 - The proposal separates WCAG conformance from the delivery
   mechanism (Web, CD-ROM), as we did in Guideline 12.

=======================================================
16) Definition of "explicit user request" slightly broken
=======================================================

The definition starts:

   "In several checkpoints in this document, the term "explicit
   user request" is used to mean any user interaction recognized
   with certainty to be for a specific purpose."

This covers the user agent's responsibility, but not whether the
user has any knowledge of the request.

--------
Proposal
--------

<NEW>
"In several checkpoints in this document, the term "explicit user
request" is used to mean any user interaction with an enabled
element or user interface control provided solely for that
interaction, and recognized by the user agent as such.
</NEW>

Comments:

 - Links, key bindings, and other user interface mechanisms that
   might have unintended effects are not included.

 - Form controls, form submit buttons, prompt confirmation
   buttons, new viewport request buttons, etc. are included.

=======================================================
17) Section 5.3: Informative references that become normative
=======================================================

--------
Proposal
--------

Add a statement that some of the references in section 5.3
"become normative" when they are used to satisfy the requirements
of checkpoint 8.2.

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

Received on Tuesday, 24 April 2001 18:39:27 UTC