Re: Proposal for eliminating two more applicability provisions and adding labeled sets

Ian,
I think I can support this proposal but I think the list of sub groups need 
to be refined.  I propose the following four sub groups:

- graphical:
3.1 (don't render background images)
3.4  (animated and blinking text)
3.5 (blinking, animations)
3.9 (don't render images)
4.1  (size of rendered text)
4.2  (font family)
4.3  (text foreground color)
4.4  (text background color)
4.14 (selection highlight with fonts and colors)
4.15 (focus highlight with fonts and colors)
8.2 (recent link highlight with fonts colors)
8.3 (fee link highlight with fonts and colors)

- audio:
2.4 (render auditory descriptions with primary audio content)
3.2 (don't render audio)
4.5 (slow audio)
4.6 (other controls of audio)
4.8 (global volume control)
4.9 (distinct source volume control)

- Video
2.4 (render captions with primary video content)
3.3 (don't render video)
4.5 (slow video and animations)
4.6 (other controls of video and animations)
4.7 (control of captions, etc. on graphical displays)

- Synthesized Speech
4.10 (speech rate)
4.11 (speech volume)
4.12 (speech characteristics)
4.14 (selection highlight with voice characteristics)
4.15 (focus highlight with voice characteristics)
8.2 (recent link highlight with voice characteristics)
8.3 (fee link highlight with voice characteristics)

Jon

At 05:10 PM 9/15/2000 -0400, you wrote:
>Hello,
>
>Eric Hansen and I had a discussion recently about some of the
>concerns that he expressed in a 5 September email [1] entitled
>"Scoring Example User Agents, etc." In particular we discussed:
>
>1) Usability of UAAG 1.0:
>    How to improve the UAAG 1.0 to make it easier to
>    make claims and to evaluate them (so that people
>    don't mistakenly compare apples and oranges).
>
>2) Minimal content/rendering requirements:
>    Must the subject of a conformance claim support
>    all of audio, video, animations, and speech? (and
>    even Braille output?)
>
>3) Further elimination of applicability provisions:
>    From section 3.4 [2], Eric felt that two of the applicability
>    provisions (one: content type, and four: output mode) are
>    problematic. Refer to previous analysis of applicability [3]
>    as well.
>
>In light of ideas generated by the discussion, I'd like
>to propose the following changes to the document that I
>feel will address some of these issues.
>
>1) Require that each conformance claim identify one or more sets
>    of checkpoints considered applicable beyond a core set.
>    These sets will bear the following labels and include
>    the following checkpoints (from the 1 September draft)
>    or portions of checkpoints:
>
>     - text:
>           4.1  (size of rendered text)
>           4.2  (font family)
>           3.4  (animated and blinking text)
>           4.14 (selection highlight with fonts)
>           4.15 (focus highlight with fonts)
>           8.2 (recent link highlight with fonts)
>           8.3 (fee link highlight with fonts)
>
>     - color:
>           4.3 (text foreground color)
>           4.4 (text background color)
>           4.14 (selection highlight with color)
>           4.15 (focus highlight with color)
>           8.3 (fee link highlight with color)
>
>     - audio:
>           2.4 (render auditory descriptions with
>                primary audio content)
>           3.2 (don't render audio)
>           4.5 (slow audio)
>           4.6 (other controls of audio)
>           4.8 (global volume control)
>           4.9 (distinct source volume control)
>
>     - visual: text group checkpoints +
>           2.4 (render captions with primary video content)
>           3.1 (don't render background images)
>           3.3 (don't render video)
>           3.5 (blinking, animations)
>           3.9 (don't render images)
>           4.5 (slow video and animations)
>           4.6 (other controls of video and animations)
>           4.7 (control of captions, etc. on graphical displays)
>
>     - speech: 4.10, 4.11, 4.12
>
>    The core set of checkpoints will be all checkpoints minus
>    those listed above.
>
>     Notes:
>      - The "visual" set is a superset of "text".
>      - 10.8 doesn't need to be in this list, I think, since it
>            refers to the applicability of other checkpoints.
>      - 10.9 (for graphical UIs) already has applicability built-in.
>
>    Is this a substantive change to the requirements of the
>    document? I don't believe so, only a change to the
>    conformance mechanism. Here's why:
>
>    We already assume that as soon as a claim includes
>    satisfaction of one requirement related to
>    audio (for example), it must include satisfaction of
>    all requirements related to audio. Defining sets of
>    checkpoints and assigning labels to them helps in
>    several ways:
>
>      a) It helps developers, who don't have to hunt around
>         to find out which checkpoints they must satisfy for
>         audio.
>
>      b) It eliminates ambiguity: the WG chooses which
>         checkpoints they mean for each content type
>         or output mode. I think the choice of which
>         checkpoints go in which sets is easy (refer to
>         previous email with similar lists [4]).
>
>      c) Labels will simplify conformance claims and
>         make them shorter. For additional convenience,
>         we might include the label "all" so that people
>         can claim to satisfy all checkpoints. Note that
>         people will not have to use a checklist to show
>         checkpoints they consider inapplicable if there
>         aren't any beyond unsupported sets. It will
>         be sufficient to say "audio and visual support"
>         and the list of inapplicable checkpoints can be
>         deduced.
>
>      d) Meaningful labels will facilitate comparison of
>         claims. (Note: these labels are only in English;
>         I rely on external RDF for internationalization).
>
>    If this conformance proposal sounds familiar, you're
>    correct! In part. Refer to an earlier proposal about media
>    types from Ian [5] and one about UI profiles
>    from Al Gilman [6]. The current proposal
>    reintroduces the notions of "subsets", which was a very
>    sticky topic back in 1998. However,
>    the current proposal differs in that the subsets
>    proposed here are already in the document -- to find
>    out how to apply the applicability provision about
>    content type (e.g., audio), claimants must search
>    for all the checkpoints with the word "audio" in them
>    and identify the set themselves. Note also that there
>    is no discussion of "native support" in the current
>    proposal.
>
>    It is NOT possible to claim to conform to a "core" set of
>    checkpoints alone, only to the core set plus at least
>    one or more sets of content/output-related checkpoints.
>    For further information on previous conformance
>    proposals, I recommend reading the summary that
>    I wrote in September 1998 [7].
>
>    Another comment: This proposal still means that someone
>    could claim "Level A" conformance and the information
>    about supported sets will not appear in the phrase
>    "Level A". We already require that claims include additional
>    information, so any valid "Level A" claim
>    must always be accompanied by information about supported
>    sets.
>
>2) Delete applicability provisions one and four
>    (content type, output mode). They are no longer required
>    due to the labels.
>
>3) Eric had requested that all user agents be required to
>    implement all content types (images, audio, video, etc.).
>    Instead, we can now require the following: for each
>    named set of checkpoints in the claim (e.g., "audio"), we
>    require the user agent to implement at least one
>    specification to support that content type.
>
>    I think this is a reasonable thing to require: If the claim
>    is that the subject supports audio, the subject
>    must in fact support audio.
>
>4) State (in the section describing the proposed labels)
>    that this document has been designed for user agents that
>    satisfy the "visual" and "audio" and "color" sets. This document
>    places less emphasis on the "speech" set and no emphasis on
>    Braille output, even though the document does not forbid
>    conformance claims for such user agents.
>
>  - Ian
>
>[1]
>http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0355.html
>[2]http://www.w3.org/WAI/UA/WD-UAAG10-20000901/#applicable
>[3] http://www.w3.org/WAI/UA/2000/08/uaag10-applic
>[4]
>http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0356.html
>[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0342.html
>[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0344.html
>[7] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0433.html
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Thursday, 28 September 2000 12:45:51 UTC