- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 18 Nov 1999 12:47:15 -0500
- To: ehansen@ets.org
- CC: w3c-wai-ua@w3.org
ehansen@ets.org wrote:
>
> Following are issues in the 5 November 1999 (Last Call) version of the UAGL
> document, not necessarily in order of criticality.
Hi Eric,
Thanks for taking the time to do this. Here we go...
> Some of the changes are marked in ALLCAPS for emphasis.
>
> Issue #1: Fix the Abstract.
>
> The abstract needs to reinforce the idea that "assistive technologies" used
> by Web browsers _are_ user agents. The old version (5 November 1999) makes
> these assistive technologies sound like they are not user agents. This
> confusion also shows up in the glossary. (The definition of "user agent"
> treats "assistive technology" as a contrast to user agents _as well as_ a
> class of user agent. This also needs to be corrected.)
The issue here is that for purposes of conformance, this document
is not meant for assistive technologies. However, you are correct
that we consider them to be user agents.
> Old:
> "Abstract:"
> "This document provides guidelines to user agent developers for making
> their products -- browsers, multimedia players, plugins -- accessible to
> people with disabilities. An accessible user agent allows users with
> disabilities to retrieve and view Web content or to enable access when used
> in conjunction with other software or hardware, called assistive
> technologies. These guidelines discuss the accessibility of the user agent
> as well as how the user agent communicates with assistive technologies such
> as screen readers, screen magnifiers, braille displays, and voice input
> software."
>
> New:
> "Abstract:"
> "This document provides guidelines to user agent developers for making
> their products -- browsers, multimedia players, and related assistive
> technologies -- accessible to people with disabilities. Developers must
> ensure: (1) that the functionalities offered by the user agent are
> accessible, and (2) that the user agent works well with other user agents
> -- especially assistive technologies -- that are necessary to access
> diverse Web content. For example, the developer of a graphical desktop Web
> browser will ensure that its functionalities are accessible by keyboard,
> since many people who are blind or have other disabilities require it. The
> developer will also use standard ways of interfacing the browser with other
> user agents, such as movie and audio players, and assistive technologies
> such as screen readers, screen magnifiers, braille displays, and voice
> input software. This document establishes criteria for three levels of user
> agent accessibility ("A", "Double-A", or "Triple-A"). User agents that are
> accessible can be more flexible, powerful, and usable for all users."
> ----
I'm not sure that I would have this much in the abstract. I think we can
drop the mention of conformance. I would drop everything from "For
example" to "Triple-A", but I could see that the keyboard proponents
might
like the keyboard mention in the abstract. The last sentence is a good
selling point.
> Issue #2. Fix the definition of "applicable checkpoint".
>
> The definition of "applicable checkpoint" has at least one significant
> problem and a few minor problems. The significant problem is that the
> definition does not handle cases in which the user agent does not
> "recognize" certain content at all. I have fixed this in the revised
> version.
>
> Old:
> {beginning of Old:}
> Applicable checkpoint
> If a user agent offers a functionality, it must ensure that all users have
> access to that functionality or an equivalent alternative. Thus, if the
> user agent supports keyboard input, it must support accessible keyboard
> input. If the user agent supports images, it must ensure access to each
> image or an alternative equivalent supplied by the author. If a user agent
> supports style sheets, it must implement the accessibility features of the
> style sheet language. If the user agent supports frames, it must ensure
> access to frame alternatives supplied by the author.
> Not all user agents support every content type, markup language feature,
> input or output device interface, etc. When a content type, feature, or
> device interface is not supported, checkpoints with requirements related to
> it do not apply to the user agent. Thus, if a user agent supports style
> sheets at all, all checkpoints related to style sheet accessibility apply.
> If a user agent does not support style sheets at all, the checkpoints do
> not apply.
> The applicability of checkpoints related to markup language features is
> measured similarly. If a user agent supports tables, it must support the
> accessibility features of the language related to tables (or images, or
> frames, or video, or links, etc.). The Techniques Document includes
> information about the accessibility features of W3C languages such as HTML,
> CSS, and SMIL.
> The following summarizes criteria for applicability. A checkpoint applies
> to a user agent unless:
> The checkpoint definition states explicitly that it only applies to a
> different class of user agent.
> The checkpoint includes requirements about a content type (script, image,
> video, sound, applets, etc.) that the user agent does not recognize at all.
> The checkpoint includes requirements about a content type that the user
> agent recognizes but does not support natively.
> The checkpoint refers to the properties of an embedded object (e.g., video
> or animation rate) that may not be controlled or accessed by the user
> agent.
> The checkpoint includes requirements about an unsupported markup language
> or other technology (e.g., style sheets, mathematical markup language,
> synchronized multimedia, metadata description language, etc.)
> The checkpoint refers to an unsupported input or output device interface.
> Note that if the interface is supported at all, it must be supported
> accessibly." {end of Old}
>
> New:
> {beginning of New:}
> Applicable checkpoint
> If a user agent offers a functionality, it must ensure that PEOPLE WITH
> DISABILITIES have access to that functionality or an equivalent
> alternative. Thus, if the user agent supports keyboard input, it must
> support accessible keyboard input. If the user agent supports images, it
> must ensure access to each image or an alternative equivalent supplied by
> the author. If a user agent supports style sheets, it must implement the
> accessibility features of the style sheet language. If the user agent
> supports frames, it must ensure access to frame alternatives supplied by
> the author.
> Not all user agents support every content type, markup language feature,
> input or output device interface, etc. When a content type, feature, or
> device interface is not supported, checkpoints with requirements related to
> it do not apply to the user agent. Thus, if a user agent supports style
> sheets at all, all checkpoints related to style sheet accessibility apply.
> If a user agent does not support style sheets at all, the checkpoints do
> not apply.
> The applicability of checkpoints related to markup language features is
> DETERMINED similarly. If a user agent supports tables, it must support the
> accessibility features of the language related to tables (or images, or
> frames, or video, or links, etc.). The Techniques Document includes
> information about the accessibility features of W3C languages such as HTML,
> CSS, and SMIL.
> The following summarizes criteria for applicability. A checkpoint applies
> to a user agent unless: {NOTE NEW ORDER OF THE BULLET ITEMS}
> (bullet) The checkpoint refers SOLELY {not sure if this is essential, may
> be OK as is} to an unsupported input or output device interface. Note that
> if the interface is supported at all, it must be supported accessibly.
> (bullet) The checkpoint definition states explicitly that it only applies
> to a different class of user agent.
> [Old - Deleted: (bullet) "The checkpoint includes requirements about a
> content type (script, image, video, sound, applets, etc.) that the user
> agent does not recognize at all."]
> (bullet) {NEW}: "The checkpoint includes requirements about a content type
> (script, image, video, sound, applets, etc.) that the user agent EITHER
> DOES NOT RECOGNIZE OR recognizes but does not support natively." {This is a
> combination of bullet points.}
> (bullet) The checkpoint refers to the properties of an embedded object
> (e.g., video or animation rate) that may not be controlled or accessed by
> the user agent.
> (bullet) The checkpoint includes requirements about an unsupported markup
> language or other technology (e.g., style sheets, mathematical markup
> language, synchronized multimedia, metadata description language, etc.)
> {end of New}
> ----
Seems good to me. I have no objection to the proposed changes.
> Issue #3. Form 2 for conformance claims lacks list.
>
> I am not sure why the "list of checkpoints that have been satisfied and
> which are considered not applicable" is required only for Form 1. Shouldn't
> it be required for both? Maybe there is a good reason why it is the way it
> is and I just don't know it. For some user agents, I think that these lists
> are extremely important.
ISSUE: SHould the details about the conformance claim always be
required?
There is an open issue about how/where to deliver a completed checklist
(suggestions welcome!) If we have a mechanism that works, we can
also have people provide details about the claim from that location.
> ----
> Issue #4. Form 2 for conformance requires rewording.
>
> Old:
>
> "Form 2: For product packaging or documentation, provide one of three icons
> provided by W3C; for Web documentation, link the icon to the appropriate
> W3C explanation of the claim."
>
> New:
>
> "Form 2: Provide Include, on product packaging or documentation, one of
> three icons provided by W3C and for Web documentation, link the icon to the
> appropriate W3C explanation of the claim."
No objection.
> ----
> Issue #5. Fix the problems with the terms "native" and "natively".
>
> In the introduction to "Priorities" and "Conformance", the use of the term
> "native" (and its variations) is extremely confusing.
>
> Please note that the sentence about satisfying requirements "natively"
> ("User agents must satisfy natively all the applicable checkpoints for a
> chosen conformance level.") is redundant with the provision in the
> definition of "applicable checkpoints" ((bullet) {NEW}: "The checkpoint
> includes requirements about a content type (script, image, video, sound,
> applets, etc.) that the user agent EITHER DOES NOT RECOGNIZE OR recognizes
> but does not support natively.").
>
> The redundancy becomes more significant when we find reference to "native
> feature" in the definition of the three priorities.
>
> There is only one problem and it needs only one solution -- not two or
> three solutions. It is a matter of logical consistency.
>
> I recommend a solution with the following steps.
>
> a. Clarify the fact that all user agents only have one set of criteria: (1)
> A user agent must provide its own functionality accessibly and (2) A user
> agent must work well with other user agents. (This is handled in an earlier
> issue in this document. That is, it is fixed at least in the Abstract. The
> rest of the UAAG document should be checked for consistency.)
Yes.
> b. Eliminate the current reference to "native" in the definition of the
> priority levels. The word is not necessary and it causes confusion. See
> below, this issue.
> c. Eliminate the reference to "natively" in the conformance section ("User
> agents must satisfy natively all the applicable checkpoints for a chosen
> conformance level."). See below, this issue.
> d. Refer to "user agent" singular as opposed to "user agents" plural, i.e.,
> "be satisfied by a user agent". This is important because any conformance
> claim pertains to a single user agent rather to the other user agents with
> which it interacts. I think that this is very important for reinforcing the
> definition of user agents.
Yes.
>
> Old:
> {beginning of Old:}
> 1.5 Priorities
> Each checkpoint in this document is assigned a priority that indicates its
> importance for users.
> [Priority 1]
> This checkpoint must be satisfied by user agents as a native feature,
> otherwise one or more groups of users with disabilities will find it
> impossible to access information. Satisfying this checkpoint is a basic
> requirement for some individuals to be able to use the Web.
> [Priority 2]
> This checkpoint should be satisfied by user agents as a native feature,
> otherwise one or more groups of users will find it difficult to access
> information. Satisfying this checkpoint will remove significant barriers to
> accessing Web documents.
> [Priority 3]
> This checkpoint may be satisfied by user agents as a native feature to make
> it easier for one or more groups of users to access information. Satisfying
> this checkpoint will improve access to the Web for some individuals.
> 1.6 Conformance
> The terms "must", "should", and "may" (and related terms) are used in this
> document in accordance with RFC 2119 ([RFC2119]).
> User agents must satisfy natively all the applicable checkpoints for a
> chosen conformance level.
> {End of Old}
>
> New:
> {beginning of New:}
> 1.5 Priorities
> Each checkpoint in this document is assigned a priority that indicates its
> importance for users WITH DISABILITIES.
> [Priority 1]
> This checkpoint must be satisfied by a user agent; otherwise one or more
> groups of users with disabilities will find it impossible to access
> information. Satisfying this checkpoint is a basic Web access {or
> "accessibility"} requirement.
> [Priority 2]
> This checkpoint should be satisfied by a user agent; otherwise one or more
> groups of users with disabilities will find it difficult to access
> information. Satisfying this checkpoint will remove significant Web access
> {or "accessibility"} barriers.
> [Priority 3]
> This checkpoint may be satisfied by a user agent; otherwise one or more
> groups with disabilities will find it somewhat difficult to access
> information. Satisfying this checkpoint will improve Web access {or
> "accessibility"}.
>
> 1.6 Conformance
> The terms "must", "should", and "may" (and related terms) are used in this
> document in accordance with RFC 2119 ([RFC2119]).
> User agents must satisfy all the _applicable checkpoints_ {extend link to
> include "checkpoints"} for a chosen conformance level. {NOTE. I DELETED THE
> WORD "NATIVELY". REMEMBER, IT IS NOT NEEDED BECAUSE IT IS ALREADY PART OF
> THE DEFINITION OF "APPLICABLE CHECKPOINT."}
> {End of New}
>
> Notes on Changes:
>
> The above changes also address problems with punctuation and consistency of
> structure in the definitions. The revised version is also more brief and
> probably easier to understand.
You're the man! I'll have to review carefully, but sounds reasonable
and consistent to me at first glance: push "native" to the definition
of applicable. Would it be confusing to say in the priority definition
"If applicable, must be satisfied..."?
> ----
> Issue #6: Checkpoints 10.1, 10.2, and 10.3 need restructuring and revision.
>
> I still a bit puzzled over 10.1, 10.2, and 10.3. I probably don't have
> enough information. I think that someone who understands what was intended
> ought to take a look at this and try to restructure it.
>
> My initial reaction was that the importance of displaying the current user
> input configuration should be the same as the importance for allowing it to
> be changed. There would seem to be no point in displaying the configuration
> unless you can modify it.
I don't recall why the ability to configure dropped from Pri 1 to Pri 2.
> Checkpoint 10.3 seems to tack on the idea of a single-stroke activation of
> changes in input configuration. I have made it a separate checkpoint. I
> feel that the _requirement_ for single-stroke changing of configuration is
> too restrictive. I prefer to _require_ "quick and direct user control" and
> _suggest_ "single stroke" as a method.
It is tacked on and used to be a separate checkpoint.
> My final reaction is partial puzzlement. I am not sure, for example, why
> and how failure to provide information about user-specified input
> configuration will make access "impossible" (Priority 1).
If you don't know what your software does, you may not be able to
use it. In particular, if author-specified bindings override what you're
used to, this can make access impossible.
> I am also not
> sure why and how providing information about user-specified input
> configuration can be more important (Priority 1) than allowing users to
> modify it (Priority 2). It doesn't seem logical. I think that this one
> needs to be revised and sent back to the list. Please see if any of my new
> versions help.
That sounds like an issue the WG needs to address.
> Old:
>
> "10.1 Provide information about the current user-specified input
> configuration (e.g., keyboard or voice bindings specified through the user
> agent's user interface). [Priority 1]"
> "Techniques for checkpoint 10.1"
> "10.2 Provide information about the current author-specified input
> configuration (e.g., keyboard bindings specified in content such as by
> "accesskey" in [HTML40]). [Priority 2]"
> "Techniques for checkpoint 10.2"
> "10.3 Allow the user to change and control the input configuration. Users
> should be able to activate a functionality with a single-stroke (e.g.,
> single-key, single voice command, etc.). [Priority 2]"
> "Users should not be required to activate functionalities by navigating
> through the graphical user interface (e.g., by moving a mouse to activate a
> button or by pressing the "down arrow" key repeatedly in order to reach the
> desired activation mechanism. Input configurations should allow quick and
> direct access that does not rely on graphical output. For self-voicing
> browsers, allow the user to modify what voice commands activate
> functionalities. Similarly, allow the user to modify the graphical user
> interface for quick access to commonly used functionalities (e.g., through
> buttons)."
> "Techniques for checkpoint 10.3"
>
> New - Alternative 1:
>
> "10.1 Provide information about the current user-specified input
> configuration (e.g., keyboard or voice bindings specified through the user
> agent's user interface). [Priority 1]"
> "Techniques for checkpoint 10.1"
> "10.2 Provide information about the current author-specified input
> configuration (e.g., keyboard bindings specified in content such as by
> "accesskey" in HTML 4.0 [HTML40]). [Priority 2]"
> "Techniques for checkpoint 10.2"
> "10.3-New. Allow the user to change and control the input configuration.
> [Priority 2]"
> "Note. This entails providing information about at least three input
> configurations (current user-specified, author-specified, and default {is
> this reference to "default" correct? At least the first two seem
> appropriate})."
> "Techniques for checkpoint 10.3"
> "10.4-New. Provide quick and direct user control of input configuration,
> such as through a single stroke (single key or single voice command)
> [Priority 2]"
> "Avoid having users make multiple strokes to activate a single
> functionality. Users should not be required to activate functionalities by
> navigating through the graphical user interface (e.g., by moving a mouse to
> activate a button or by pressing the "down arrow" key repeatedly in order
> to reach the desired activation mechanism. Input configurations should
> allow quick and direct access that does not rely on graphical output. For
> self-voicing browsers, allow the user to modify what voice commands
> activate functionalities. Similarly, allow the user to modify the graphical
> user interface for quick access to commonly used functionalities (e.g.,
> through buttons)."
> "Techniques for checkpoint 10.4"
>
> New - Alternative 2:
>
> {Delete: "10.1 Provide information about the current user-specified input
> configuration (e.g., keyboard or voice bindings specified through the user
> agent's user interface). [Priority 1]"
> "Techniques for checkpoint 10.1"}
> {Delete: "10.2 Provide information about the current author-specified input
> configuration (e.g., keyboard bindings specified in content such as by
> "accesskey" in HTML 4.0 [HTML40]). [Priority 2]"
> "Techniques for checkpoint 10.2"}
> "10.1-NewAlt2. Allow the user to change and control the input
> configuration. [Priority 2]"
> "Note. This entails providing information about at least three input
> configurations (current user-specified, author-specified, and default {is
> this reference to "default" correct? At least the first two seem
> appropriate})."
> "Techniques for checkpoint 10.1"
> "10.2-NewAlt2. Provide quick and direct user control of input configuration,
> such as through a single stroke (single key or single voice command)
> [Priority 2]"
> "Avoid having users make multiple strokes to activate a single
> functionality. Users should not be required to activate functionalities by
> navigating through the graphical user interface (e.g., by moving a mouse to
> activate a button or by pressing the "down arrow" key repeatedly in order
> to reach the desired activation mechanism. Input configurations should
> allow quick and direct access that does not rely on graphical output. For
> self-voicing browsers, allow the user to modify what voice commands
> activate functionalities. Similarly, allow the user to modify the graphical
> user interface for quick access to commonly used functionalities (e.g.,
> through buttons)."
> "Techniques for checkpoint 10.4"
The WG should discuss this proposal.
More comments later on the rest,
- Ian
Received on Thursday, 18 November 1999 12:47:29 UTC