Proposal for fixing checkpoints 10.2, 10.3, 10.4, 10.7

Dear UAWG,

A few days ago, I sent an email [1] proposing some changes regarding
our checkpoints relating to visual highlight of selection, focus, 
and a couple of other pieces of information. There's been a fair 
amount of discussion on the list, and I'd like to summarize some of 
the key points in preparation for discussion at tomorrow's
teleconference.

After the summary, there is a proposal that Jon and I support.
We welcome your comments.

Reference document: 12 Sep 2002 CR
   http://www.w3.org/TR/2001/CR-UAAG10-20010912/

  - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0124

---------------------
Summary of key points
---------------------

1) I believe that the purpose of checkpoints 10.2, 10.3, 10.4, and
  10.7 is to ensure that users making use of a graphical user
  interface can distinguish five classes of information
  (selection, focus, enabled elements, visited links, and fee
  links) through a configurable highlight mechanism.

  Note: Guideline six requires that information about selection,
  focus, and content be available through an API. We included
  those requirements so that ATs would not have to rely on
  rendered highlights (e.g., boxes) to figure out the range
  of the selection. While ATs certainly *may* use that technique,
  I don't think that we should be including requirements (notably
  at P1) that fly in the face of our goal to communicate this
  information through an API.

2) The specific accessibility needs we are trying to meet here
  are:

  a) To ensure that users can specify their own colors in order
     to overcome difficulties with particular combinations;

  b) To ensure that users with an extremely limited color
     capabilities colors (e.g., users with macular degeneration
     who rely exclusively on black and white) can still
     distinguish the five classes of information that interest
     us. If, for example, a user must view white text on a black
     background, then, the user agent must make available
     highlight mechanisms that do not rely on text foreground and
     background colors (limited to only black and white).

  These two scenarios suggest that we will have one requirement
  for configuration, and another related to highlight styles
  not based on text colors alone.

3) A sentence such as "the selection highlight mechanism must not
  rely on color alone" is confusing, because it suggests that
  a highlight mechanism that relies on color alone does not satisfy
  the requirement. I believe that what we intended to say was:
  "The UA must provide at least one highlight mechanism that does
  not rely on color alone."

  In its current form, checkpoint 10.3 makes requirements on
  *default* highlight styles. If these defaults do not respect
  operating environment conventions, however, this is likely to
  confuse some (indeed, many) users. User agent developers are
  very unlikely to implement default highlight styles that
  conflict with operating environment conventions. Checkpoint
  7.1 (P1) already requires that selection and focus be implemented
  according to operating environment conventions.

  Note: The second provision of 10.3 currently says that the
  checkpoint does not apply to those highlight styles inherited from
  the operating environment as default values, as long as the user
  can change the styles in the operating environment. In practice, we
  have seen developers claim conformance to 10.3 even though the
  first provision (which makes stricter provisions than simple
  inheritance) has not been satisfied. This seems to be a loophole
  in the document that is cleared up by the proposal below.

4) The WCAG 1.0 requirement for the author to not rely on
  color alone is about the author encoding information; don't
  encode meaning in color alone. In UAAG 1.0, since the values
  of these five classes of information are available through an
  API per Guideline 6, the checkpoints in Guideline 10 are only
  about rendering, not encoding semantics.

--------
Proposal
--------

As Jon pointed out on this thread, we are proposing the
following hierarchy of requirements:

  1. Ensure that the user can configure highlight styles.
  2. Observe operating environment conventions.
  3. Allow the user to create and use profiles.

The following checkpoint combines and replaces checkpoints 10.2,
10.3, and 10.4. The most important change here is that the
highlight configuration requirement for content goes from P2 to
P1.

New 10.x (P1), five provisions:

  1. Provide a global mechanism for highlighting the selection and
    content focus of each viewport, as well as all enabled
    elements, recently visited links, and fee links in rendered
    content.

  2. For each of these five classes of information, provide
    at least one highlight mechanism (e.g., underline or
    border) that does not rely on text foreground and
    background colors alone.

  3. Allow the user to configure the highlight mechanisms for
    these five classes of information so that they are
    distinguishable in the same viewport at the same time.

  4. For graphical viewports, if a highlight mechanism
    involves text size, font family, colors, or text
    decorations, offer the following range of values:

     1) for text size, same range described in checkpoint 4.1;
     2) for font family, same range described in checkpoint 4.2;
     3) for colors and text decorations, offer a range
        that includes at least:

      * the range offered by the conventional utility available in
        the operating environment that allows users to choose
        colors or text decorations (e.g., the standard font and
        color dialog box resources supported by the operating
        system).

      * or, if no such utility is available, the range of colors
        or text decorations supported by the conventional APIs of
        the operating environment for specifying colors or
        drawing text.

  5. Highlight enabled elements according to the granularity
    specified in the format. For example, an HTML user agent
    rendering a PNG image as part of an image map is only
    required to highlight the image as a whole, not each enabled
    region. An SVG user agent rendering an SVG image with
    embedded graphical links is required to highlight each
    graphical link that may be rendered independently according
    to the SVG specification.

   Note: Examples of highlight mechanisms for selection and
   content focus include foreground and background color
   variations, underlining, distinctive synthesized speech
   prosody, border styling, etc. Because the selection and focus
   change frequently, user agents should not highlight them using
   mechanisms (e.g., font size variations) that cause content to
   reflow as this may disorient the user. Examples of highlight
   mechanisms for links and other content include foreground and
   background color variations, font variations, underlining,
   distinctive synthesized speech prosody, border styling, etc.

   Note: Per checkpoint 7.1, follow operating environment
   conventions that benefit accessibility when implementing
   the selection and content focus.

New 10.y (P2), one provision:

  1. Allow the user to configure via a single setting the
    highlight mechanisms for the five classes of information
    described in checkpoint 10.x so that they are distinguishable
    in the same viewport at the same time, and do not rely
    on text foreground and background colors alone.

    Note: If the user agent satisfies this requirement, the
    user agent automatically satisfies provision 3. of checkpoint
    10.x. See also checkpoint 11.6, which requires the user agent
    to allow the user to save configurations in a user profile.

------------------------
Comments on the proposal
------------------------

  - In the techniques document, be sure to document why
    we require mechanisms that do not rely on text fg and
    bg color alone (e.g., for users with macular degeneration).

------------------------------------
Proposed revision to checkpoint 10.7
------------------------------------

In its current form, checkpoint 10.7 (intentionally) does not
require user configuration of viewport highlight style, as long
as the default highlight does not rely on color alone.  I propose
the following changes for consistency with the proposed 10.x
above. The revision no longer talks about default styles and
adds a configurability requirement *only* for the non-text
foreground/background highlight style.

Revised 10.7 (P1):

  1. Provide a global mechanism for highlighting the viewport with
  the current focus (including any frame that takes current
  focus).

  2. Provide at least one highlight mechanism (e.g., a thick
  outline) that does not rely on text foreground and background
  colors alone.

  3. For graphical viewports, if the highlight mechanism required
  by the previous provision involves text size, font family,
  colors, or text decorations, offer the same ranges of values
  required by checkpoint 10.x.

  Note: Per checkpoint 7.3, follow operating environment
  conventions that benefit accessibility when implementing
  the viewport highlight mechanism.

  Note: Since checkpoint 6.5 requires notification of changes
  in user interface focus through an API, this checkpoint does not
  require that user agents indicate changes in focus through
  a text message in the user interface.

Additional comment on the current checkpoint 10.7: The Note says
that it's a special case of checkpoint 1.1; I think that's a bug.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Thursday, 4 April 2002 10:25:04 UTC