Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

Dear Michael Zapp,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.


Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: Minimum contrast needed for default layout in case 1.4.3 is
met via a contrast control
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0056.html
(Issue ID: 2434)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

It seems somewhat imbalanced to require web designeres to stick to a
quite limited colour palette on the one hand - and allowing them to
more or less ignore the success criteria on the other hand simply by
including a contrast control on the page.

Even a web site with extremey low contrast (e.g. light grey text on a
white background) can easily comply to 1.4.3 if the designer only adds
an unobstrusive style switcher somewhere at the bottom of the page. We
feel this might encourage web designers to ignore colour contrast
issues altogether for the default layout and rely solely on the style
switcher for compliance with 1.4.3.

While this would probably hardly affect users with severe colour
vision deficiencies (as anyone who absolutely requires certain colour
combinations will need to adjust his browser settings anyway), it
might impair accessibility for people with mild colour vision
deficiencies significantly. These users would be forced to search for
the style switcher, figure out how it works and check the options it
offers again and again on every site they visit.

Proposed Change:
The default layout should have a minimum colour contrast to begin
with, e.g. a contrast ratio of 3:1, even if there is a contrast
control providing higher contrast levels.

Also the guidelines should specify that the contrast control itself
should have a contrast ratio of at least 5:1 and be positioned at the
top of the page. It should also be labeled clearly in text form (and
not just designed as a tiny and possibly ambiguous icon).

---------------------------------------------
Response from Working Group:
---------------------------------------------

We considered this at length and we have left 1.4.3 Contrast (Minimum)
at level AA. There are ways, using either operating system or User
Agent 'highlighting' or 'contrast' tools/features to create high
contrast text. For example, setting the system highlight to always
highlight text as black text on yellow background.  It is also
possible to create a simple tool that will detect text with very low
contrast (see juicy studio for an analysis engine that does so) and
use this technique to auto highlight text with very low contrast.

Since there are ways to make text high contrast, we did not require it
at Level A due to the restrictions it places on color palettes.

We agree that consumers are not always aware of all the accessibility
features in browsers and operating systems.  There are also users who
do not have access to software.  However, we feel there is a limit to
the extent to which authors should have to make up for limitations on
users awareness or skills with tools that are available to them. In
this case, we do not feel that this provision should be a level A
provision since the need can be met with techniques available to the
users.

Regarding your second suggestion - yes - the control would have to be
visible itself.

Because there were a number of questions about the note and there are
other success criteria where similar notes would apply, we have
removed the note and updated the titles of the sufficient techniques
that describe the use of controls.

For 1.4.3 (situations A and B):
Providing a control with at least a 5:1 contrast ratio that allows
users to switch to a presentation that uses sufficient contrast
(future link)

For 1.4.6 (situations A and B):
Providing a control with at least a 7:1 contrast ratio that allows
users to switch to a presentation that uses sufficient contrast
(future link)

Other provisions cover the other aspects of it such as font size etc.

----------------------------------------------------------
Comment 2: Why do contrast requirements not apply to lines in diagrams and such?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0057.html
(Issue ID: 2435)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Why do contrast requirements only apply to text and images of text?
What about other important parts of informative images - such as lines
in diagrams, icons or symbols in maps etc.? Or what about other
non-text-elements such as the borders of input fields?

Users can define their own colours for text in all modern user agents,
however they cannot control the color in images. Therefore sufficiant
contrast is even more important for images than for text.

Proposed Change:
All essential parts of a web page need to have sufficient contrast -
not only text and images of text.

---------------------------------------------
Response from Working Group:
---------------------------------------------

We originally looked at including content like icons and graphs. Upon
examination, however, we found that they were often complex, involved
multiple 'foreground' and 'background' objects and often involved
multi-color and multi-luminance objects.

So, we included them in advisory but did not include a success
criterion that covered them because we could not figure out how to
write one that would have the desired effect without unduly limiting
the appearance of complex graphical items.

----------------------------------------------------------
Comment 3: Background images disappear with user-specific colors
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0058.html
(Issue ID: 2436)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Users with severe colour vision deficiencies will often need to set
their user agents to display specific foreground and background
colors. However this also causes all background images to disappear.
This is not sufficiently addressed in the current draft.

A related problem apparently also currently not addressed: images with
transparent backgrounds may not be visible/legible on a user-specific
background color.

Proposed Change:
The guidelines should specify that images that convey important
information should not be included as background images.

This is actually already addressed in F3 (Failure of Success Criterion
1.1.1 due to using CSS to include images that convey important
information) - however this failure only relates to success criterion
1.1.1 and blind users (as CSS-images can have no alternative text). It
should also relate to users with color deficiencies.

The guidelines should also specify that any image containing important
information must remain visibible/legible regardless of the background
color.

---------------------------------------------
Response from Working Group:
---------------------------------------------

If something is already prohibited by one success criterion, then it
is not necessary to create another, especially if it is at level A. SC
1.1.1 is not for blind users. It is for all users. In this case, by
requiring alternate text for any image, it would prevent the problem
you cite and handle any foreground image that became unintelligible
because the background was a particular color.

We have added the following note to F3 to capture your concern, so
that it is clearer.

"Embedding information into a background image can also cause problems
for people who use alternate backgrounds in order to increase
legibility and for users of high contrast mode in some operating
systems. These users, would lose the information in the background
image due to lack of any alternative text."

----------------------------------------------------------
Comment 4: Why the exception for proper names and technical terms?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0059.html
(Issue ID: 2437)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

In Germany English proper names and technical terms are usually
pronounced according to English pronounciation rules - so that is how
they should be pronounced by screen readers. (Examples: "Firefox",
"fieldset", "label" ...)

If a proper name or technical term has not become part of the language
mainly used in a web document, the only way to make sure it is
pronounced properly is to use the lang attribute. (e.g. <span
lang="en">Firefox</span>)

Proposed Change:
Make it clear that proper names and technical terms in different
languages also often need to be identified as such using the lang
attribute.

---------------------------------------------
Response from Working Group:
---------------------------------------------

Good idea.  We have added an advisory technique that reads, "Providing
language markup on proper names to facilitate their proper
pronunciation by screen readers".

It is advisory because it is not always appropriate or effective where
a name might be pronounced differently in different places in order to
be understood. Another argument for excluding proper names is that you
often don't know where a proper name comes from, especially with names
of products.

----------------------------------------------------------
Comment 5: Is it proven that the new algorithm for calculating
brightness is superior to the old one?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0060.html
(Issue ID: 2438)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

The Techniques For Accessibility Evaluation And Repair Tools (W3C
Working Draft, 26 April 2000) suggested an algorithm for calculating
the brightness of an RGB value. Empirical surveys were conducted on
this for verification and the algorithm was and still is actually used
in practice.

In this old algorithm the RGB-components were weighted as follows:

0.299 * R + 0.587 * G + 0.114 * B

The suggested new calculation of brightness uses a different weighting, namely:

0.2126 * R + 0.7152 * G + 0.0722 * B

Was the old algorithm faulty? And if it wasn't: is it proven that the
new algorithm is more appropriate in this area of application?

Proposed Change:
Proof for the superiority of the new algorithm for the calculation of
brightness.

---------------------------------------------
Response from Working Group:
---------------------------------------------

The new WCAG 2.0 algorithm was chosen because it is much more
consistent in its results. For one thing the old algorithm was
calculated in non-linear color space while the new algorithm is
calculated in in linear terms.  There is no way to correctly calculate
contrast in non-linear space. It will give you irregular results (good
results in some areas of the color space and bad results in others).

See  definition of Y in sRGB colorspace equation 1.8 in "A Standard
Default Color Space for the Internet - sRGB  at
www.w3.org/Graphics/Color/sRGB

The new WCAG 2.0 rule also is based on luminance contrast alone -
whereas the old measure included color contrast as well.  This causes
the old algorithm to fail things that have plenty of visual contrast
for people with all types of color limitation.  For example some color
combinations will fail the old tool even though they are eminently
readable and have a luminance contrast of 15:1 or more  (where 21:1 is
pure black on white).   Very dark charcoal gray on yellow (contrast
ratio of 16:1) would fail the old algorithm. 100% green on black (same
as old CRTs) (contrast ratio of 15:1) would also fail the old
algorithm.

Having said all that, the new contrast ratio was chosen to be somewhat
less stringent than the old - in order to provide a larger color
palette for authors who are trying to meet the provision.

IN SUMMARY: The new algorithm is a better overall algorithm.  However,
the values chosen for use with the new algorithm (5:1) do result in a
somewhat less strict level for some color combinations.  This was done
to allow a somewhat less restricted number of colors when creating
pages that could meet the criterion. However, the new criterion is
more strict than the old in some areas.

Received on Tuesday, 11 March 2008 00:20:40 UTC