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

See comments below:

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Tuesday, April 24, 2001 6:39 PM
> To: w3c-wai-ua@w3.org
> Cc: tantek@cs.stanford.edu
> Subject: [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).

EH: This raises the issue: Must one read the Techniques document to know
whether a checkpoint applies? Ideally, UAAG 1.0 should be sufficient to
guide the user on that point. Or if they need guidance from the Techniques
document to make that determination, then perhaps that needs to be noted for
specific relevant checkpoints.

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

EH: The foregoing language may be OK, but in general, I think that we should
temper our emphasis on making improvements for "all users". One reason for
this tempering is something that relates to the notion of equal access. I
think that our primary focus is and should be on improving access for people
with disabilities. Period. Improvements for people without disabilities are
a possible secondary effect. Interestingly, such a secondary affect is not
always desirable. For example, in the area of educational testing, a change
or accommodation that improves the performance people WITH disabilities but
has _no benefit_ for people WITHOUT disabilities, is more likely to be a
"valid" accommodation (one that does not change what is being measured) than
does an accommodation that benefits BOTH test takers WITH disabilities and
those WITHOUT disabilities (if the latter were allowed to use the
accommodation). In essence, an accommmodation that benefits test takers both
with and without disabilities arguably does nothing to "level the playing
field."

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.
> 
EH: Seems reasonable.

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

EH: Seems reasonable.

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

EH: Ok.
> 
> ================================
> 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>
> 
EH: Its an improvement.

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

EH: Ok.
> 
> ================================
> 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>
> 

EH: Ok.

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

EH: Ok.
> 
> ================================
> 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.
> 
EH: Ok.
> =======================================================
> 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.
> 
EH: Ok.

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

EH: Good change.

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

EH: Probably fine.

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

EH: Seems necessary.

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

Received on Thursday, 10 May 2001 10:45:15 UTC