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

(unknown charset) Re: Part II: Issues raised during Mac IE evaluation of UAAG 1.0

From: (unknown charset) Jon Gunderson <jongund@uiuc.edu>
Date: Mon, 1 Apr 2002 22:28:50 -0600 (CST)
To: (unknown charset) "Ian B. Jacobs" <ij@w3.org>
cc: (unknown charset) <w3c-wai-ua@w3.org>
Message-ID: <Pine.GSO.4.31.0204012221000.19101-100000@staff1.cso.uiuc.edu>
Some people only see in black and white (using the rods of their retina)
so different shades of gray are hard to distinguish.  So having a highlight
not dependent on color or sahdes of gray is important to some disabilities
to easily recognize highlighting and important element on a page.  Jacob
Neilson also recently reported that skilled web surferes with
visual impairments only complete tasks about a 20-33% percent as much
as their able bodied peers.  When they do complete a task it takes them
about twice as long.

So I don't like the idea of removing the "differ from color" clauses.

Was there a technical reason Tantek said this could not be done?


On Sat, 30 Mar 2002, Ian B. Jacobs wrote:

> 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
> document.
>   - Ian
> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0085
> [2] http://www.w3.org/WAI/UA/implementation/report-cr2
> ===========
> Substantial
> ===========
> --------
> 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
>      colors?
>   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
> Summarizing:
>   * 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
>      viewports."
>      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
> intended.
> If the user agent has a "Restore defaults" button that cancels
> the user's configuration when restoring the default settings, is
> that a problem?
> Proposal:
> =======================
> Editorial/Clarification
> =======================
> ------------
> 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
> includes:
> 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 Monday, 1 April 2002 23:28:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:31 UTC