Proposal for eliminating two more applicability provisions and adding labeled sets

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

Received on Friday, 15 September 2000 17:10:49 UTC