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

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?

Jon


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