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:59:35 -0700
Message-ID: <824e742c0711032159td2708q42f9524f5a778adc@mail.gmail.com>
To: "Magnus Burell" <magnus.burell@verva.se>
Cc: public-comments-WCAG20@w3.org

Dear Magnus Burell,

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: Replace term "visually rendered"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0309.html
(Issue ID: 2164)
Original Comment:

The term "visually rendered" in SC 1.4.4 and SC 1.4.7 is jargon.
Hence, the guideline would benefit from an explanation in more plain

Response from Working Group:

We have changed the success criteria (1.4.4 and 1.4.7) to say:

"Text (but not images of text) can be resized ...."

Comment 2: Add video-clips to illustrate solutions
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0310.html
(Issue ID: 2165)
Original Comment:

3.3 is quite abstract. To make the guidline clearer, add short
video-clips that show how this can look when implemented.

For examples of how video can help illustrate a suggested solution,
see videos explaining interaction design patterns at Yahoo.com.

Click "Play" in the image:

Video could also be added to explain other success criterias such as
"onfocus" in SC 3.2.1 and "oninput" in SC 3.2.2

Response from Working Group:

This would be helpful supplementary information, but the working group
does not have the resources to create these videos at this time. We
would be glad to consider adding any submission of this type.

Comment 3: Change alternative number two "Checked"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0311.html
(Issue ID: 2166)
Original Comment:

Alternative number two †Checked† does not give the user feedback
or an opportunity to actually accept the change that will occur. If
the submitted data is correct for the system (e.g. contains no
formatting errors) but the transaction leads to, from a user’s point
of view, unexpected changes. Then it could be an idea to inform the
user about what the action might lead to.

Proposed Change:
For example: "Changing your X information will make  . Do you want to?
Yes No". Therefore as written now, I suggest "Checked" is removed from
the list in 3.3.3. The check for input errors could be made before or
after the "Confirmed" step.

Response from Working Group:

Note 3.3.3 is now 3.3.4. We have changed bullet 2 to clarify that the
user is provided an opportunity to correct any errors that are
"Data entered by the user is checked for errors before going on to the
next step in the process and the user is provided an opportunity to
correct them."

While bullet 3 will potentially let the user catch more errors, it
does not provide the user any assistance in finding errors. Since the
user will often be presented with data that contains no errors, we are
concerned that it may encourage users to ignore the confirmation step.
So it is not required in addition to bullet 2.

We have also added an example to Understanding SC 3.3.4 to demonstrate
checking for a potential input error that is not a syntax error but
may produce unexpected results:

Stock sale: A financial services web site lets users buy and sell
stock online. When a user submits an order to buy or sell stock, the
system checks to see whether or not the market is open. If it is after
hours, the user is alerted that the transaction will be an after-hours
transaction, is told about the risks of trading outside of regular
market hours, and given the opportunity to cancel or confirm the

Comment 4: Present more techiques on how improve texts
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0312.html
(Issue ID: 2167)
Original Comment:

To make the guideline more understandable, present more techiques on
how to do this and give further advise on how to test it.

Proposed Change:
For example:

Sufficient techique: Try writing the most important first. Not only in
the summary, also in the text as a whole and in separate sentences. It
would support the reader's ability to choose if och if not to continue

Advisory Techique: An enumeration with more than four posts should be
written as a list. This makes it easier to get an overview of the
page. For example "bananas, apples, pineapples, peaches, mangos" could
be easier to read formattes as a li-list in HTML:

-       bananas
-       apples
-       pineapples
-       peaches
-       mangos

Response from Working Group:

We would be happy to include references to writing at a lower reading
level, but we believe that this is too large a topic to include this
information directly in the Understanding WCAG document.

We have added references to the
"Guidelines for Creating Easy to Read Text, The Open Society Mental
Health Initiative" at   http://www.osmhi.org/?page=139
and the
"European Guidelines for the Production of Easy-to-Read Information
for People with Learning Disability"  at

Could you please send us additional references on this topic, for
inclusion in the Related Resources section of the success criterion?

Comment 5: Let the user use her preferred format for input
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0313.html
(Issue ID: 2168)
Original Comment:

Is it not easier for the user if the requried format is corrected by
the system without user involvement when applicable? For example a
field for Telephone number. Phone numbers could be written separated
by several characters (e.g. . / - () ). Separators are different in
different countries. It is not difficult to let the system erase
unnecessary separators. For example if the user input is
"+64(8)555-9999-33" then the system transform this into "648555999933"
or "0064.8.555.999.933" or whatever format is needed, but the user do
not need to worry about this. She can instead write phone numbers in
the way she is used to.

This could of course be complemented by a text description of the
format the system "prefers".

Response from Working Group:

Note 3.3.2 is now 3.3.3
Providing as much flexibility as possible in the input format is
helpful for reducing errors. We have added the advisory technique:
Accepting input data in a variety of formats

However, it will still be possible for the user to enter data that the
system cannot interpret and transform reliably, and the success
criterion should be satisfied.

Comment 6: Use heading for different columns in web page layouts?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/03014html
(Issue ID: 2169)
Original Comment:

2.4.9 Section Headings: Where content is organized into sections, the
sections are indicated with headings

In SC 2.4.9, do you suggest headings (hidden with CSS or visual) for
different columns in web page layout? For example a hidden heading
"Navigation" for left-menu, only shown for people listening to the
page or not using CSS. Plus the main-heading for the content showing
"here starts the main column" and finally some heading for an
additonal right column.

Response from Working Group:

To clarify, we have modified the success criterion to say:
"Section headings are used to organize the content."

"Note: This success criterion covers sections within writing, not user
interface components. User Interface components are covered under
Success Criterion 4.1.2"

The success criteria addresses text and subject matter. The intent is
to take text that would otherwise be continuous text and divide it up
so that it is easier for people with cognitive disabilities to access
and understand.
Received on Sunday, 4 November 2007 04:59:54 UTC

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