- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 22 Mar 2001 11:14:10 -0500
- To: "UA List (E-mail)" <w3c-wai-ua@w3.org>, "Ian Jacobs (E-mail)" <ijacobs@w3.org>
This was accidently sent prior to finishing, but only to Ian. See followup
message that comes next.
-----Original Message-----
From: Hansen, Eric
Sent: Thursday, March 22, 2001 8:52 AM
To: 'Ian Jacobs'
Subject: RE: [Conformance] Proposals regarding content/ui labels, input
device conformance, and conformance example
Comments below:
> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Wednesday, March 21, 2001 5:54 PM
> To: w3c-wai-ua@w3.org
> Subject: [Conformance] Proposals regarding content/ui labels, input
> device conformance, and conformance example
>
>
> Hello,
>
> Please consider the following proposal, which I hope resolves a few
> remaining conformance issues:
>
> 1) Is a given checkpoint for content only, for the user agent's
> features only, or for both?
>
> 2) How should conformance work for pointing device and voice input?
>
> 3) Which checkpoints do I have to satisfy to conform?
>
> Reference document: 19 March 2001 draft [0]
> [0] http://www.w3.org/WAI/UA/WD-UAAG10-20010319/
>
> ==========
> Proposal 1
> Label checkpoints for content, user agent, or both.
> ==========
>
> There are currently 87 checkpoints in the document. Some of them
> apply to author-supplied content only, some to components of
> the user agent only, and some to both. I am quite convinced of
> the following:
>
> a) Forty-five checkpoints apply to author-supplied content only:
>
> Guidelines 2, 3, 4 (except 4.16), 5.4, 5.5, 6.1, 6.2, 6.3, 6.9,
> Guideline 8, 10.1, 10.3, 10.4, 10.5, and 11.2.
>
> b) Thirty-two checkpoints apply to components of the user agent only
> (i.e., everything but the content):
>
> 1.2, 6.4, 6.7, Guideline 7, Guideline 9, 10.6-10.10, 11.1,
> 11.3-11.6, and Guideline 12.
>
> c) Seven checkpoints apply to both:
>
> 1.1, 4.16, 6.5, 6.6, 6.8, 6.10, and 10.2.
>
> Today, we have "informative" labels for identifying whether a
> checkpoint is for content only, for the user agent only, or for both.
> I think we need to make this clear in a normative fashion and propose
> the following:
>
> a) At the end of each checkpoint statement, next to the priority,
> indicate (using some sort of label) whether the checkpoint is for
> content only, for the user agent only, or for both.
>
> b) Add a conformance section to which these labels would link
> (and introduce the labels at the beginning of section 2 on
> the structure of a checkpoint definition). The conformance
> section might read something like this:
>
> <NEW 3.x>
> 3.x Checkpoints for content, user agent features, or both
>
> For some requirements of this document, "content" (the document
> object) is distinguished from "user agent features" (everything
> else besides the document object). User agent features include
> functionalities provided by the user agent out of the box, native
> user interface components, documentation, focus and selection, etc.
>
> For conformance, a user agent is required to satisfy the
> requirements of the checkpoint for content only, for user agent
> features only, or for both.
> </NEW 3.x>
>
> c) Delete the various informative groupings:
>
> * Checkpoints for content accessibility
> * Checkpoints for user interface accessibility
> * Checkpoints for communication with other software
> * Checkpoints for accessible documentation
>
> Note: Some of them are already misleading in the 19 March 2001
> draft. For instance, checkpoint 1.1 is listed as being for
> the user interface, but it also applies to content.
>
> d) Add to the definition of DOM something like the following
> statement:
>
> "Most of the requirements of this document apply to content (i.e.,
> the document object) after its construction. However, a few
> checkpoints (e.g., 2.7, 2.8, and 2.10) may affect the construction
> of the DOM."
>
EH: Good.
> e) Reformat the checklist so that checkpoints are no longer grouped
> according to the labels of (c) but rather according to whether
> for content, for ui, or for both.
>
> ==========
> Proposal 2
> Conformance for pointing device input and voice input
> ==========
>
> I recently sent a proposal [1] for addressing some concerns about
> conformance for pointing device input and voice input. I'd like
> to amend that proposal slightly.
>
> a) To conform, all input device requirements must be satisfied for
> the keyboard.
EH: Good.
>
> b) To conform for pointing device input and voice input, the same
> input device requirements must be satisfied for those input
> devices, substituting "voice" or "pointing device" for "keyboard"
> wherever it appears (namely in checkpoints 1.1, 6.7, 9.3,
> and 11.3).
>
> However, there is one exception to this rule: checkpoint 11.3
> refers to *single key access*. This requirement does not (I would
> argue very strongly) translate to pointing device and voice input.
> (I would argue this strongly because, while ease of access is
> certainly a consideration, we developed this requirement very
> specifically for single-physical-key access. I would not want
> to try to generalize in this document to "single spoken gesture",
> for example).
>
> Because checkpoint 11.3 includes some requirements that are
> specific to the keyboard and some that are not, I propose to split
> the checkpoint in two (so that conformance will be easier to
> understand). This would give:
>
> 11.3a Allow the user to override any binding that is part of the
> user agent default input configuration. The user agent is not
> required to allow the user to override standard bindings for the
> operating environment (e.g., for access to help). [Priority 2]
>
> 11.3b Allow the user to override any binding in the default
> keyboard configuration with a binding of a single key and
> (possibly zero) modifier keys. Allow the user to assign a single
> key binding (with zero modifier keys) to at least a majority of
> the functionalities available in the default keyboard
> configuration. [Priority 2]
>
EH: Issue 1: Proposal to split. It seems good. So 11.3a would apply voice
and pointer input and 11.3b would not.
Issue 2: 11.3b has been changed sometime recently but it seems not to make
sense. Specifically, the requirement to "Allow the user to assign a single
key binding (with zero modifier keys) to at least a majority of the
functionalities available in the default keyboard configuration" may
sometimes be impossible to follow. Suppose there are 250 functionalities
available through the keyboard in the 'default keyboard configuration'. This
checkpoint would require that there be a 'single key binding (with zero
modifier keys) to at least a majority" i.e., 126, of the functionalities.
Yet there are less than 126 such single key binding(s) (with zero modifier
keys) available on the keyboard. It seems that this needs to be fixed.
> c) Update the input modality label definitions as follows:
>
> Pointer:
> This input modality label refers to all of the input device
> requirements of this document, applied to pointing device
> input, except for checkpoint 11.3b. For all other
> checkpoints, substitute "pointing device" for "keyboard"
> in the checkpoints.
>
> Voice:
> This input modality label refers to all of the input device
> requirements of this document, applied to voice input,
> except for checkpoint 11.3b. For all other
> checkpoints, substitute "voice input" for "keyboard"
> in the checkpoints.
>
> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0452
>
> ==========
> Proposal 3
> Some edits to section 3.1 Conformance model
> ==========
>
> <NEW 3.1>
>
> The conformance model of this document has been designed to allow
> different types of user agents with different input and output
> capabilities to conform. At the same time, this flexible model
> includes requirements about conformance claims themselves so that:
>
> a) people reading claims can determine whether a conforming user
> agent is likely to meet their accessibility needs, and
>
> b) people can compare claims about disparate user agents with
> relative ease. Note: The checklist [UAAG10-CHECKLIST] may be
> used when evaluating a user agent for conformance.
>
> The conformance model works as follows:
>
> - A user agent conforms to this document by satisfying a set of
> requirements. Conformance requirements *only* come from the
> checkpoint statements. Each checkpoint statement includes one or
> more requirements.
EH: Old:
>
> - Different user agents may conform to different sets of
> checkpoints. The formula below explains how to calculate a set
> of requirements that must be satisfied for conformance.
>
EH: New:
> - Different user agents may conform to different sets of
> checkpoints. The formula below explains how to determine a set
> of requirements that must be satisfied for conformance.
IJ:
> - Conformance claims must indicate how the set of requirements
> chosen for the claim differs from the "default" set. Please note
> that this document includes both conformance requirements and
> conformance claim requirements.
EH: Good.
IJ:
>
> The "default" set of requirements for conformance consists of all
> the requirements of all of the checkpoints. A user agent
> "conforms unconditionally" to this document if it satisfies all
> of the requirements of all of the checkpoints.
>
> A user agent "conforms conditionally" if it satisfies any set of
> requirements that results from carrying out all of the following
> steps:
>
> 1) Choose a conformance level. Each conformance level
> corresponds to a set of checkpoints (and thus a set of
> requirements).
EH: Good.
IJ:
>
> 2) Remove the requirements associated with any unsupported
> content type labels. In order to conform conditionally, a user
> agent must satisfy the requirements of at least one content type
> label.
>
> 3) Remove the requirements of any checkpoints or parts of
> checkpoints that do not apply.
>
> Note: In the default set of requirements, the only input device
> requirements relate to keyboard input. It is also possible to
> claim conformance for pointing device input and voice input; see
> the section on input modality labels.
EH: Good.
>
> EXAMPLE
>
> Consider a user agent with these capabilities:
>
> * it supports keyboard and pointing device input;
EH: Old:
> * it renders text (in color) and several formats for
> images, audio, and animations;
EH: New
> * it renders text (in color) and several formats each for
> images, audio, and animations; [CHECK WORD PLACEMENT]
IJ:
> * it hands of video to a plug-in;
> * it doesn't support speech output.
>
> Step 1) Choose a conformance level. The claimant wishes to
> conform at level Double-A. The resulting set of requirements
> consists of all of the requirements of all the priority 1 and 2
> checkpoints.
>
> Step 2) Remove requirements related to content type labels.
> The claimant wishes to claim conformance for the user
> agent's support of text, images, audio, and video, but no other
> animation formats.
EH: It is a bit jarring to see video as an animation format, perhaps a link
to glossary of other explanation is warranted.
IJ:
Since video is supported through a plug-in,
> the plug-in must be in the conformance claim. The following
> content type labels are therefore relevant: VisualText,
> ColorText, Image, Animation, Video, and Audio. This means that:
>
> * the claimant must remove the set of requirements associated
> with the Speech content type label.
>
> * the claimant must satisfy the requirements associated with
> the other content type labels.
>
> Step 3) Remove requirements that do not apply. Consider
> checkpoint 4.4, for example, which is associated with both the
> Audio and Animation content type labels:
EH: On the topic of recognition, this "example" is one of several possible.
One can make the case that in the current environments, checkpoint 2.5 ("")
does not apply.
IJ:
>
> 4.4 Allow the user to slow the presentation rate of audio and
> animations (including video and animated images). For a visual
> track, provide at least one setting between 40% and 60% of the
> original speed. For a prerecorded audio track including audio-only
> presentations, provide at least one setting between 75% and 80% of
> the original speed. When the user agent allows the user to slow the
> visual track of a synchronized multimedia presentation to between
> 100% and 80% of its original speed, synchronize the visual and
> audio tracks. Below 80%, the user agent is not required to render
> the audio track. The user agent is not required to satisfy this
> checkpoint for audio and animations whose recognized role is to
> create a purely stylistic effect. [Priority 1]
>
> Suppose that:
>
> a) The claimant wishes to claim support for two audio formats;
> b) The claimant wishes to claim support for one video format;
> c) The claimant does not wish to claim support for two
> animation formats (since the user agent doesn't
> satisfy the requirements of 4.4 for those implemented formats);
EH: This list seems to contradict the earlier implication that video formats
would be a "kind of" animation format....
IJ:
> d) The claimant does not wish to claim support for synchronized
> multimedia (since the user agent doesn't
> implement any synchronized multimedia formats).
>
> The resulting requirements from this checkpoint would be:
>
> a) For the audio formats:
> Allow the user to slow the presentation rate of audio. For a
> prerecorded audio track including audio-only presentations,
> provide at least one setting between 75% and 80% of the original
> speed.
>
> b) For the video format:
> Allow the user to slow the presentation rate of video. For a
> visual track, provide at least one setting between 40% and 60% of
> the original speed.
>
> c) Limitation of scope for any format:
> The user agent is not required to satisfy this checkpoint for
> audio and animations whose recognized role is to create a purely
> stylistic effect.
>
> The following requirements do not apply:
>
> a) When the user agent allows the user to slow the visual track of a
> synchronized multimedia presentation to between 100% and
> 80% of its
> original speed, synchronize the visual and audio tracks.
> Below 80%,
> the user agent is not required to render the audio track.
>
> The relevant applicability provision is provision three
EH: "of section 3.x:"
IJ:
> control of a content property that the subject cannot
> recognize. In this case, no format implemented by the user
> agent supports synchronized multimedia.
>
> Step 4) Construct a well-formed conformance claim. For this
> example (in addition to other required information), the claim must
> include the following information:
>
> a) Conformance level Double-A
> b) Information about the subject, in this case the combination
> of a multimedia user agent and a plug-in for rendering video.
> c) Content type labels: "This user agent does not support
> the requirements of the Speech content type label. This
> user agent supports the requirements of the Animation
> content type label for the format X, but does not for the
> formats Y and Z."
EH: It seems necessary to do as you have done -- to indicate which formats
are _implemented but for which no support is claimed_ (Y and Z) as well as
for which ones support is claimed (X). Should this be made any more
explicit?
IJ:
> d) Requirements that do not apply: "The synchronized multimedia
> requirements of checkpoint 4.4 do not apply because the user
> agent does not implement any formats that support
> synchronized multimedia.
>
> Note: Since the user agent does not meet the requirements of the
> Pointer and Voice input modality labels, the claim does not
> include them.
> </NEW 3.1>
>
> Comment:
>
> a) I refer to "requirements" rather than "checkpoints" throughout
> this section since a single checkpoint may include more than one
> requirement. I need to make sure that section 3 uses the term
> "requirement" rather than "checkpoint" in a uniform manner.
>
> Your comments welcome,
>
> - Ian
>
> --
> Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
> Tel: +1 831 457-2842
> Cell: +1 917 450-8783
>
Received on Thursday, 22 March 2001 11:19:48 UTC