W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

Your comments on WCAG 2.0 Public Working Draft of May, 2007

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:35:43 -0700
Message-ID: <824e742c0711032135t91537cyd881570ac978d04a@mail.gmail.com>
To: "Mary Frances Laughton" <Laughton.MaryFrances@ic.gc.ca>
Cc: public-comments-WCAG20@w3.org

Dear IAC Canada,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

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 May-October 2007 at

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.


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: Keep 2.4.4 as a Level-A Success Criterion.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0385.html
(Issue ID: 2252)
Original Comment:

The Government of Canada (GoC) feels strongly that requiring that the
link purpose (context) be associated with a hyperlink remain a Level-A
Success Criterion.  While fully cognizant that the ability to render
link-text or link-metadata apart from its context is a user-agent
feature - and thus not necessarily ought to be a driver for
content-markup techniques, we feel that enough people use the
link-list features of their user-agents to warrant keeping this
Success Criterion at Level A.  The GoC feels it is necessary to remind
the WCAG that a primary aim of the Guidelines is to inform page
authors how to make CONTENT more accessible.  We feel that meaningful
link purpose in context benefits enough end users to maintain this at
Level A. The GoC also recognizes that there are some cases where
context might be immediately ascertainable and where repetitive link
purpose text might be needlessly redundant (e.g. in tables of links).

Proposed Change:
No change - leave as Level A Success Criterion.

Response from Working Group:

We agree, and SC 2.4.4 remains at Level A with some adjustments to the
SC language so it now reads:
2.4.4 Link Purpose (In Context): The purpose of each link can be
determined from the link text alone, or from the link text together
with its programmatically determined link context, except where the
purpose of the link would be ambiguous to users in general.

Comment 2: A new Success Criterion regarding use of color.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0386.html
(Issue ID: 2253)
Original Comment:

Some sites become essentially unusable (e.g. parts of Facebook.com)
when viewed under (Windows OS) high-contrast display rendering schemes
and certain user agent settings (accessibility color options) that are
used by some people with low vision.  We are in the process of doing
further research on this topic to determine if this warrants a new
success criterion or whether an advisory technique would be
sufficient.  One advisory might emphasize the need to ALWAYS
explicitly set appropriate foreground/background colors (since the
cascade doesn't always seem to work as expected). Another might be to
recommend designers test their designs against the range of OS
Accessibility display renderings.

Proposed Change:
Please consider a new Success Criterion, "A site should be (operable,
perceivable...etc) without relying on color.  Moreover, the site
should not depend on a specified foreground or background color."

Response from Working Group:

Not depending on color is already mostly covered by provision 1.4.1.

1.4.1 Use of Color: Color must not be used as the only visual means of
conveying information, indicating an action, prompting a response, or
distinguishing a visual element. (Level A)

The main issue with high contrast settings is that non-standard system
default colors are applied to the page. If authors fail to override
the default for one color, a system color that they may not have
anticipated will be used. This situation is addressed by Failure F24.

F24: Failure of SC 1.4.3 and 1.4.5 due to specifying foreground colors
without specifying background colors or vice versa"

There are a couple additional ways to fail that we did not include. So
we are adding the following failures.

Failure of 1.4.3 and 1.4.5 due to using background images that do not
provide sufficient contrast with foreground text.

Failure of SC 1.1.1 due to using CSS to include images that convey
important information.

Comment 3: An advisory on anti-aliased fonts.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0387.html
(Issue ID: 2254)

Original Comment:

This comment also applies to 1.4.5 and may also apply to the
Techniques Document.

While the requirement for using a formula to assure a sufficient
foreground/background luminosity ratio is clear for solid color
elements, and even reasonable for most dithered elements against solid
or dithered elements (i.e. through averaging dithered values), one
situation should be highlighted as an advisory: anti-aliased fonts
especially at small default sizes can be very difficult for some
people with reduced visual acuity to distinguish from background even
if the "average" contrast ration appears within range.  At small
sizes, even a black stroke core can be rendered as a lighter gray by
the anti aliasing dither: moving out from the core the pixel become
lighter still.  In the particular example that brought this comment a
small anti-aliased font was set against a white background.  Two
evaluators, one with low vision, and one with 50-year-old eyes had
great difficulty reading the text until it had been enlarged (e.g.
using Internet Explorer 7's "Change Zoom Level" control to 150%
enlargement). The Understanding Success Criterion 1.4.3 and 1.4.5
entries mention: "Note 3: Text can be evaluated with anti-aliasing
turned off" we do not feel that this provides designers with
sufficient information about the use of small dithered font colors.

Proposed Change:
GoC recommends adding a discussion and/or examples to illustrate this problem.

Response from Working Group:

We have added the following to UNDERSTANDING.
"When fonts have anti-aliasing applied to make them look smoother,
they can lose darkness or lightness.  Thus, the actual contrast can be
reduced. Thicker stem widths will reduce this effect (thin fonts could
have the full stem lightened rather than just the ends). Using larger
fonts and testing for legibility in user agents with font smoothing
turned on is recommended."

Comment 4: Significant improvement over previous drafts
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0384.html
(Issue ID: 2295)
Original Comment:

The Government of Canada (GoC) is pleased to see the many changes made
to the WCAG 2.0 Guidelines and supporting documents since the previous
Last Call Working Draft. Most, if not all, of the changes have the
effect of improving both the understandability and usability of the
guidelines  at least to people well versed in the field of accessible
Web site design. Meeting the twin goals of general appeal and
technical rigor is difficult to attain but this draft comes closer to
that than any other to date.  The GoC looks forward to such features
as being able to extract or reformat the information in the supporting
documents (presumably in a similar fashion to the Quick Reference
guide) and to the fleshing out of techniques, advisories and examples
where there are only placeholders at the moment.

Response from Working Group:

Thank you for taking the time to comment on WCAG.  A lot of time and effort
has gone into the draft and it has been difficult at times to find the best
language to express the requirements and advice when it needs to apply
across such a wide (and expanding) variety of technologies. We think that,
although not perfect, this draft is a significant advance in the right
direction.  We look forward to new research that is being done on the Web
and on Accessibility that will allow us to go even further in future
Received on Sunday, 4 November 2007 04:36:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC