W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > March 2008

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Mon, 10 Mar 2008 17:18:47 -0700
Message-ID: <824e742c0803101718t2705c95eq624214562d2f7b52@mail.gmail.com>
To: "Carlos Iglesias" <carlos.iglesias@fundacionctic.org>
Cc: public-comments-WCAG20@w3.org

Dear Carlos Iglesias,

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

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
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.


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: Concerns about 80 characters width limit
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0046.html
(Issue ID: 2497)
Original Comment:

Having into consideration that the number of characters per line may
be affected by different parameters (window size, screen resolution,
font-size...) that are not controllable by the content creator, this
requirement may be quite difficult (not to say impossible) to fulfill.

Additionally readability may be also equally affected when the line
width is to narrow, so I don't understand why to put just top limits
in case of put any.

Response from Working Group:

First, it should be noted that if the author does not set the column
width but lets the text wrap as it will, then he satisfies this
success criterion. It is only when authors set the column width to
fixed values that are more than 80 characters wide that a problem
arises.  Note that the success criterion says, "a mechanism is
available".  It is only when the author defines font and column width
etc. in such a way that the user cannot achieve an 80 character line
length that the author creates a problem.

Regarding your question about narrow line widths, we found that very
few pages exhibit this problem without good reason. While authors can
take steps to make it possible for users to view line lengths of 80
characters, adding requirements for minimum width has the potential to
introduce the need for users to scroll horizontally on some devices.

Comment 2: Concerns about text resizing requirements
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0048.html
(Issue ID: 2499)
Original Comment:

Note that the requirement of text resizing up to 200 percent in a way
that does not require user scroll horizontally may implicitly means
\"do not use elastic (em based) designs\" and that give us just
\"liquid (% based)\" designs as the only option for flexible designs.

Proposed Change:
Maybe an alternative linear design via a switch control could be
suggested as an alternative way to comply with this requirement.

Response from Working Group:

Success criterion 1.4.8 included the technique, "Providing options
within the content to switch between layouts that use a variety of
font sizes (future link)."

To clarify, we have revised this technique title to read, "Providing
options within the content to switch to a layout that does not require
the user to scroll horizontally to read a line of text (future link)."

Comment 3: Criteria to evaluate essential things
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0049.html
(Issue ID: 2500)
Original Comment:

The criteria to decide whether something is essential is really
ambiguous (especially when you are dealing with graphic designers ;o).

For example, could the use of an image for the presentation of text
using some "non-standard" font on headers to follow the "look & feel"
of a specific brand be considered essential for the information

(Note that if you say no you are saying that the look & feel of a
brand doesn't convey any information)

Response from Working Group:

We have added a definition for 'essential'.

 if removed, would fundamentally change the information or
functionality of the content, *AND* information and functionality can
not be achieved in another way that would conform

Because the information and functionality of the content would not be
fundamentally changed by the removal of a specific font style in
headings for brand identity, your example would not qualify for the

This means that Level AAA conformance could not be achieved if you
wanted to preserve look and feel beyond logotypes.

Comment 4: User agents' incorrect behaviour while navigating sequentially
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0050.html
(Issue ID: 2501)
Original Comment:

Due to some user agents' behaviour, several embedded elements that are
in theory operable through keyboard (for example a flash component if
correctly developed) are not reachable through keyboard while
navigating sequentially.

How is this success criterion going to affect these elements?

Could people say that such a web page pass this success criterion?

Response from Working Group:

In a case like this - where it is a shortcoming of one browser, but
not a problem with other browsers - we would say that it was a
reasonable assumption by the author that the user could exit. The
Working Group would encourage the author to provide an additional
redundant function which allows the user to exit that they know does
work in most browsers.

Refer to Understanding Accessibility Support for additional information.

Comment 5: Sequential navigation and meaning
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0051.html
(Issue ID: 2502)
Original Comment:

Once a web page has any focusable element it can be navigated
sequentially, and we can't think about a use case where the sequence
doesn't affect meaning, so we don't see the need of the conditionals
here and they can add confusion.

Response from Working Group:

An example would be a number of articles that contains links, arranged
on a page where there is no real relationship between the articles, so
they can be presented in any order. There is no one linear order that
is more meaningful than another.

Hence, the qualifier is needed.

Comment 6: Sections Headings conformance level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0052.html
(Issue ID: 2503)
Original Comment:

Can't imagine why this success criterion has been "degraded" to AAA
level, as we think it's widely recognized as a really useful and
important one.

Response from Working Group:

We had a number of comments that mistake the purpose of success
criterion 2.4.10 and success criterion 1.3.1.

Success criterion  1.3.1, which is at level A, requires that anything
that looks like a heading is marked up as a heading.

Success criterion 2.4.10 says that anywhere you could use a heading,
you have to insert one.  This provision is included at level AAA
because it cannot be applied to all types of content. It is often not
possible to insert headings. For example, if you are posting a
pre-existing document, you do not have the ability to insert headings
that an author did not include in the original document. Or, if you
have a long letter, it would often cover different topics, but putting
headings into a letter would be very strange.

However, if a document can be broken up into sections with headings,
it facilitates both understanding and navigation. For this reason, it
is a success criterion. But, because it can't always be done (or be
appropriate) it is at level AAA.

We have added this explanation to Understanding SC 2.4.10.

Failure F2 also speaks to this:

F2: Failure of Success Criterion 1.3.1 due to using changes in text
presentation to convey information without using the appropriate
markup or text.

Comment 7: Use of roles with current technologies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0053.html
(Issue ID: 2504)
Original Comment:

This sounds like requiring the use of WAI-ARIA while it's still work
in progress. We think that doesn't make much sense.

Response from Working Group:

HTML links and form controls have names and roles built into user
agents. If you are using HTML, all that is required is that you use
these elements rather than building look-alike controls with CSS and
script. ARIA, when it is finished and supported, will provide another
way to set these values in HTML.

Many other technologies that already exist also support name and role.
Some examples are Flash, Java, and ActiveX controls.

Comment 8: Conformance and use of accessibility-supported tehcnologies
in a non-conforming way
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0054.html
(Issue ID: 2505)
Original Comment:

There are five conformance requirements, and you need to fulfill all
of them if you want to be conformant.

If you use accessibility-supported technologies in a non-conforming
way you don't satisfy the first requirement (Conformance Level) and so
you are not going to be conformant.

So, we think that the reference to accessibility-supported
technologies that are used in a non-conformance way here just add
confusion, as it could lead to the conclusion that you can be
conformant using accessibility-supported technologies in a
non-conformance way.

Response from Working Group:

This provision is needed for the following situation.

Example: There is a page that incorporates a new interactive graphic
technology called ZAP. Although ZAP is accessibility-supported, the
information that is presented in ZAP is also presented on the page in
HTML, so ZAP is not relied upon. So, this page would pass conformance
requirement #1.  However, if the user tries to tab past the ZAP
content, the focus drops into the ZAP object and gets stuck there.
Once inside, there is nothing the user can do to get the focus back
out.  So keyboard users cannot use the bottom half of the page. The
ZAP content also is continually flashing brightly at different rates
and doesn't stop.   So, people with attention deficit are distracted
and those with photosensitive seizure disorders may have seizures.
Conformance requirement #5 prevents situations like these from being
possible on a conforming page.

To make this clear, we have added this example to the section titled
understanding conformance requirement #5.

Comment 9: Conformance logos
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0055.html
(Issue ID: 2506)
Original Comment:

There is no mention to WCAG conformance logos. Is there any plan to
create WCAG 2.0 conformance logos?

If so, how is going to be the relation between logos and conformance claims?

Once you use the logo, are you required to make a conformance claim?

Proposed Change:
Logos, if any, should be treated as conformance claims and the
provision of the same information must be required.

Response from Working Group:

There are currently no plans for a conformance logo. However, if one
is used, it would constitute a claim and should be accompanied by the
information described in "Required components of a conformance claim."

Comment 10: Accessibility supported (lists of Web technologies)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0056.html
(Issue ID: 2507)
Original Comment:

The whole WCAG 2.0 relies on the concept of Accessibility supported
technologies, but the provision of any list of Web technologies with
Accessibility Support is avoided, making thus WCAG 2.0 unusable in
practice until anybody else will do it.

Proposed Change:
At least it must be explicitly exposed that, in absence of any other
accessibility supported web technologies list, the wider choice must
be used (i.e. just HTML as the onlly accessibility supported web

Response from Working Group:

The working group recognizes that the need for information on which
technologies are 'accessibility-supported' is important to use of the

Such data can only come from testing different versions of user
agents and assistive technology and recording whether the features of
the technology are supported. We expect that this information may
need to be compiled from multiple sources. WAI will be working with
others to establish an approach for collecting information on the
accessibility support of various technologies by different user
agents and assistive technologies.

WCAG 2.0 is still in development. We expect that during Candidate
Recommendation period we will have some initial information on
accessibility supported technologies, to demonstrate how this
approach will work once WCAG 2.0 becomes a W3C Recommendation.

The Candidate Recommendation process itself requires that there be
examples that demonstrate conformance. So there will certainly be some
information about accessibility supported technologies in order to get
out of the candidate recommendation stage for WCAG 2.0.

Comment 11: Contrast ratio (on text edges)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0057.html
(Issue ID: 2508)
Original Comment:

It is not clear how to proceed in the case of images of text that have
an edge around the letters (see an example at [1])

[1] - [http://url.ctic.es/f]

Proposed Change:
It is supposed that you should use the edge color as foreground color
or as a background color for the font face. This may this need to be
clarified at the contrast ratio explanation [1] in the same way as was
made for dithered colors for example.

[1] - [http://www.w3.org/TR/WCAG20/#contrast-ratiodef]

Response from Working Group:

As defined, an edge around the letter would allow it to meet the
provision - and this is held up by visual experience.  Since it likely
isn't clear to all, we will add the following note to the definition
of contrast ratio.

Note: When there is a border around the letter, the border can add
contrast and would be used in calculating the contrast between the
letter and its background. A narrow border around the letter would be
used as the letter.   A wide border around the letter that fills in
the inner details of the letters acts as a halo and would be
considered background.

And add the following note to the definition of Relative Luminance.

Note: WCAG conformance should be evaluated for color pairs specified
in the content that an author would expect to appear adjacent in
typical presentation. Authors need not consider unusual presentations,
such as color changes made by the user agent, except where caused by
authors code.
Received on Tuesday, 11 March 2008 00:19:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:10 UTC