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

This is probably useful to developers and people trying to compare 
conformance claims.  I like the idea of a user agent having to support a 
technology associated with a subset in order to claim conformance to that 
subset.  I don't know how many people would try to claim conformance to a 
media type they don't support, but I think this makes conformance tighter.

My suggestions:
1. I think visual should include checkpoints related to images, text and 
color; maybe call it graphical instead
2. Audio is fine
3. Speech is fine
4. I would make video stand alone like audio and speech

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 Monday, 18 September 2000 18:06:44 UTC