W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2002

Part II: Issues raised during Mac IE evaluation of UAAG 1.0

From: Ian B. Jacobs <ij@w3.org>
Date: Sat, 30 Mar 2002 00:42:06 -0500
Message-ID: <3CA5502E.3070602@w3.org>
To: w3c-wai-ua@w3.org
Dear UAWG,

This is part two of a list of issues raised as a result of my
review with Tantek Çelik of Mac IE. The previous issues are
available at [1]; the review itself should be integrated shortly
into our implementation report [2].

I think there are two substantial issues in this email, and five
requiring less important clarifications or editorial changes.

Many thanks to Tantek for his ongoing support of this

  - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0085
[2] http://www.w3.org/WAI/UA/implementation/report-cr2


Issue 1) Checkpoint 10.3. Distinct default highlight styles.
This checkpoint is problematic for a number of reasons:

  a) Someone who can read visually displayed text must
     find *some* combination of foreground and
     background text colors suitable. UAAG 1.0 doesn't
     have any color contrast requirements, but we
     assume that if users can select colors, they can
     select colors that contrast sufficiently.

  b) Checkpoint 10.3 requires that the default styles
     for selection and content focus, as well as for
     enabled elements, recently visited links, and fee
     links in rendered content (1) not rely on color alone, and
     (2) differ from each other, and not by color alone.

     Why must they not rely on color alone? It makes sense
     to tell *authors* that they must not rely on color alone
     to convey information; semantics must be conveyed in a
     manner that does not rely on a single output mode.

     User agents are another story. Graphical user agents
     convey almost meaning through the GUI using shades
     of color (including black, white, and grey). Since
     UAAG 1.0 requires that information about content,
     selection, etc. be available to ATs through
     APIs (see Guideline 6), why should the graphical
     highlight styles be required not to depend on
     color alone as long as the user can override those

  c) Checkpoint 10.3 also requires that the highlight
     styles for 5 types of information differ from each
     other and not by style alone. One problem with this
     requirement is that it is likely to lead to
     uncommon behavior in the user interface, especially
     if operating environment conventions rely on color.
     For instance, if the operating convention for
     selection is inverting text foreground and background
     colors, that shouldn't worsen readability as long
     as the contrast between the two colors was sufficient
     to begin with. In other words: if a user can't
     make use of two colors, inverting those colors won't
     make matters worse. So reverse video, which relies
     on color alone, should not be forbidden; what is necessary
     is that the user be able to change the colors to
     ensure sufficient contrast.

  d) UAAG 1.0 does not include any requirements that the
     default ordinary text rendering ensure sufficient
     color contrast. That would seem to be more important
     than ensuring that the default rendering for
     fee links have sufficient color contrast. I believe
     that ensuring sufficient contrast by default is at
     best a low priority requirement.

  e) If we force user agents to adopt non-standard rendering
     for links, etc., we are likely to decrease usability for
     most users as they are accustomed to a particular rendering
     today. Consider Jakob Nielsen's Top Ten
     mistakes of Web Design (from 1999 [1]): number 8 says
     that it's a mistake (for authors) to use non-standard
     link colors. It would clearly be a mistake for user agents
     to render links using non-standard colors by default, or
     indeed mechanisms that did not rely on color alone.

     [1] http://www.useit.com/alertbox/990502.html


  * We are talking here about graphical rendering, and graphical
    rendering relies on color to a large extent. The accessibility
    requirement is primarily adequate contrast, which is met
    by allowing the user to choose colors.

  * The user agent should inherit colors from operating environment
    configurations, but this is not a P1 requirement.

Therefore, I propose the following changes:

  0) Delete provision 2 of checkpoint 10.2:

     "The highlight mechanism must not rely on color alone."

  1) Delete checkpoint 10.3 or change it to a P2
     requirement relating to consistency with operating
     environment settings (see checkpoint 7.2):

     "Follow operating environment conventions for highlighting
     selection and content focus, enabled elements, recently
     visited links, and fee links in rendered content."

     Note: I could see leaving the part of 10.3 that says
     "Ensure that the default styles for these things differ
     from each other." I would remove the clause
     "and not by color alone."

  2) Make 10.4 a P1 checkpoint (from P2). The following
     checkpoints would then ensure at a P1 level user control
     of color as follows:

     4.3: Foreground and background colors for rendered text.
    10.2: Selection and content focus.
    10.4: Enabled elements, recently visited links, and
          fee links in rendered content.

  3) Delete the second sentence of provision 10.4.2.:
     "The highlight mechanism must not rely on color alone."

  4) Delete the second and third provisions
     of checkpoint 10.7 (Highlight current viewport):

     "2. For graphical viewports, the default highlight mechanism
      must not rely on color alone.

      3. This default color requirement does not apply if the
      highlight mechanism is inherited from the operating
      environment as the default and the user can change it in the
      operating environment."

  5) Add a P2 requirement (formerly the third provision of 10.7):

     "Follow operating environment conventions for highlighting

     Note: I have not added a requirement to allow the user
     to override colors when colors are used to highlight
     viewports. I think that in most cases, this should be
     offered at the operating environment level. This may
     not be the case for frames.

Issue 2) Checkpoint 11.6 User profiles

The first provision of the checkpoint is:

  1. For the configuration requirements of this document, allow
  the user to save user preferences in at least one user profile.

Does the user agent satisfy this requirement simply by allowing
the user to save various configurations (that then take effect
when the UA is next launched)? Or is the requirement that the
profile be somehow portable, i.e., removable from the user agent,
applicable to the same UA on another machine, etc.?  The
checkpoint doesn't convey that requirement if that's what was

If the user agent has a "Restore defaults" button that cancels
the user's configuration when restoring the default settings, is
that a problem?



Editorial 1) Provision 4 of checkpoint 10.4 is hard to
understand.  Proposal:

    "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."

Editorial 2) Fix markup of glossary instances in the text so that
text content and underlines are the same color.

Editorial 3) Checkpoint 10.8: Indicate rendering progress
This checkpoint is about the viewport's position in rendered
content, not download progress. To avoid confusion, the
checkpoint title should be "Indicate viewport position". We
may also want to state clearly in the checkpoint that this
is *not* a requirement to indicate download progress.

Secondly, I think that one goal of this checkpoint is
that this information be available as text. I think our intention
was that, since this information is a message to the user,
checkpoint 1.3 covers the text requirement. This could be
clarified with some kind of cross reference to checkpoint 1.3.

Editorial 4) Checkpoint 11.5 Default binding requirements

The list of required functionalities for the default bindings

a) "Enter URI for new resource". Clarify that there may be
    several ways to satisfy this, such as by prompting the
    user, or moving the cursor to the address box.

b) "Refresh rendering". This may be confusing with our
    use of the term "refresh" in checkpoint 3.5. We need to
    define our terms and intention carefully:

    - In checkpoint 3.5, refresh means "Fetch content at
      the same URI"
    - In checkpoint 11.5, reload means "Fetch content at
      the same URI," and refresh means "Redraw the same
      content without fetching new content." This definitely
      needs to be cleaned up. I propose that we use the
      term "fetch" in checkpoint 3.5. In 11.5, I suggest
      that we say "Re-render same content (i.e., redraw)"
    - Similarly, we say "stop loading resource". I presume
      that this means "interrupt the current fetch request".

c) "Forward/back one viewport". I suggest that we say
    very specifically that in a two-dimensional rendering, this
    corresponds to "page down/up" and depends on the dimensions
    of the viewport. Does "one viewport forward" make sense
    in a one-dimensional rendering?

Editorial 5) Checkpoint 12.3 Document default bindings

If the user agent does not allow the user to override
default input bindings, then documentation of default
bindings (12.3) satisfies checkpoint 11.1. Therefore,
the two checkpoints should refer to each other.

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Saturday, 30 March 2002 00:42:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:32 UTC