- From: Ian B. Jacobs <ij@w3.org>
- Date: Sat, 30 Mar 2002 00:42:06 -0500
- 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
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 Saturday, 30 March 2002 00:42:26 UTC