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 19:33:52 -0700
Message-ID: <824e742c0711031933r32081e3du9f7a9c8c0770b17e@mail.gmail.com>
To: "Yukie Motomiya" <yukie.motomiya.zm@hitachi.com>
Cc: public-comments-WCAG20@w3.org

Dear Yukie Motomiya,

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
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

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: Grounds for "200%"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0283.html
(Issue ID: 2112)
----------------------------
Original Comment:
----------------------------

We have two questions on 1.4.4 and 1.4.7:

 Q1. Why "200%" and "50%"?

 Q2. Why do the authors have to be responsible for "200%"?


We couldn't understand the reason why the authors should ensure that
the "visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent". In the section
of "Intent of this Success Criterion", it reads "The working group
feels that 200% is a reasonable accommodation that can support a wide
range of designs and layouts, ...". However there should be more
concrete reason why the working group feels "200%" and "50%" are
reasonable. Also we'd like to know this percentage can be applied to
the characters in any other languages such as CJK languages.


Additionally, all the authors have to do is to use relative
measurements in order to make text resizable. Do these SC mean that
the authors should provide the mechanism with users to resize text up
to 200 percent and down to 50 percent? If so, it should be done by the
user agents.

Proposed Change:
- Add the concrete reason why "200%"/"50%" and the sufficient grounds
for any other languages than English. Or change these SCs to simply
saying "Visually rendered text can be resized by the user agents
without assistive technology."

- Add the concrete reason why "authors" should be responsible for
"200%" and "50%".

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

The working group spent a lot of time discussing such options; in
fact, some of our initial proposals looked very much like your
suggestion, "Visually rendered text can be resized by the user agents
without assistive technology." However, we discovered several
problems.

As text is scaled larger and larger, it becomes impossible to prevent
loss of content or functionality. When horizontal text is enlarged
beyond a certain level, text wrapping algorithms turn the text into a
vertical column of words, possibly clipped if the word itself is too
large to fit into the available horizontal space on screen. For
vertical text, similar problems occur.

Arbitrary resizing also introduces problems with testing. How does an
author know when he has satisfied the success criterion, particularly
for more sophisticated web pages that may change their layout  based
on the text size to produce more readable results. An example would be
a page that switches between single and multiple column text so that
line widths stay within the ~16 word range recommended for some
cognitive, learning, and language disabilities.

So we felt that some choice of explicit values was necessary to make
these success criteria testable. 200% was chosen after experimenting
with various web pages that the working group felt were well designed,
to see when scaling started to introduce problems. We also looked at
the scaling supported directly by popular browsers. (IE's largest text
scaling factor is only about 180%). And we looked at the support
provided by screen magnifiers. For older screen magnifiers, 200% was
the smallest scale factor that could be chosen. 50% was chosen to
provide symmetry in the ranges. The ability to scale in both
directions is desirable.

We believe that there is a range of visual disabilities that can best
be addressed directly and a range where the most effective solutions
rely on assistive technology such as screen magnifiers. Other success
criteria ensure that assistive technology can access the content
successfully. These new success criteria identify the author's
responsibility when supporting users where direct access is more
effective.

Note, by the way, that the success criteria don't require just scaling
to 200% and 50%, but to all the values between. Our expectation is
that solutions that work across that range will continue to work "as
well as possible" beyond those limits.

This is explained in the Intent Section of Understanding SC 1.4.4. The
Working Group welcomes suggestions for ways to make this information
clearer.

----------------------------------------------------------
Comment 2: How to measure dB(A) SPL and Tools
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0284.html
(Issue ID: 2113)
----------------------------
Original Comment:
----------------------------

We'd like know how to measure the volume in dB(A) SPL. Are there any
tools which alows the authors to measure the volume easily?

Proposed Change:
- Add how to measure the volume in dB(A) SPL

- Introduce the tools for the authors to measure the volume in dB(A) SPL

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

Technique G56 will answer questions for people who have a beginning
knowledge of making audio. It introduces different way of determining
audio contrast.

There are three basic ways described in G56:
1) Use an audio creation tool to measure the contrast as its being created.
2) Listen to the examples (sufficient and failure) provided in G56 and
test it that way.
3) Measure the final wave form in an inexpensive (less than $100)
audio program such as Cool Edit Pro.

A separate tutorial is available which we will link to from the
Additional Resources section of Technique G56. It provides a more in
depth description of how to create and measure audio content on the
web, as well as a discussion of popular tools used in the creation of
audio for the Web and how to measure volume in dB(A) SPL. It is here:
www.eramp.com/david/audio_contrast_general_techs.htm

----------------------------------------------------------
Comment 3: Time Limit for Security/Access Control
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0285.html
(Issue ID: 2114)
----------------------------
Original Comment:
----------------------------

There can be the time limit for:

- the security reasons

- the access control(system/network performance management)



If the users are not allowed to turn off, adjust, and/or extend the
time limit in such cases, what should the authors do? These cases also
should be the exception.

Proposed Change:
Add the followings to GL 2.2.1

 - Security Exception: the time limit is  required for the security
reason, and no alternative to the time limit is possible; or

 - Access Control Exception: the time limit is  required for the
system/network performance management, and no alternative to the time
limit is possible.

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

Those situations were kept in mind when the current language was
crafted. Use of time limits for security concerns relates to not
leaving a terminal open. By asking if the user needs more time, you
know that they are still present. So the extend provision would allow
security concerns to be met.

RE Access Control Exception:   There is a limit on the number of times
a person can extend.  So access is eventually returned.  If the
exception were allowed, then people who need 5 or 10 times more time
to complete would never be able to.  The number of people who would be
sitting on their terminals requesting more time at each time out is
small enough that that it should not cause any problem in overall use
of system resources.

----------------------------------------------------------
Comment 4: Layout using CSS
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0289.html
(Issue ID: 2118)
----------------------------
Original Comment:
----------------------------

In the last sentence within the "Description" section, it reads "When
the source order does not match the visual order, the tab order
through the content must reflect the logical relationships in the
content that are displayed visually."

What if the author positions the groups of the content in the
different order than the source order by using CSS? For example, a web
page contains the navigation bar and the main content. In the visually
rendered order, the navigation bar is placed first in the content, the
main content is placed second. However, in the source order, the main
content is placed first and the navigation bar is placed second. In
this case, the visually displayed order does not much the source
order, but the tab order through the logical relationships and
sequences make sense. Is this applied to G59 technique?

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

Positioning different sections of the content via CSS would satisfy SC
2.4.3, since focus would follow logical order within each section of
the page, and there is no logical requirement that the sections be in
any relative order. We have added such an example to Understanding SC
2.4.3.

We have also added a new success criterion at Level A that the focus
order be consistent with the information and relationships conveyed
through presentation. While there are sometimes several orders that
would be consistent with the information and relationships conveyed
through presentation, we do not feel that your proposed example would
meet this new success criterion.

----------------------------------------------------------
Comment 5: 3.2.3 should be Level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0292.html
(Issue ID: 2121)
----------------------------
Original Comment:
----------------------------

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated
on multiple Web pages within a set of Web pages  occur in the same
relative order each time they are repeated, unless a change is
initiated by the user. (Level AA)



It's safe to say that these SCs are the common practices in the web
design and "support the ability of both mainstream and specialized
user agents to adapt content to formats that meet their users' needs".

Proposed Change:
Move 3.2.3 to Level A.

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

This is too broad a requirement to have at level A. There are reasons
where it may be desirable, more usable and more understandable to
change the order of the navigation elements from one page to another.
This was level AA in WCAG 1.0 as well.

----------------------------------------------------------
Comment 6: 3.2.4 to level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0296.html
(Issue ID: 2125)
----------------------------
Original Comment:
----------------------------

3.2.4 Consistent Identification: Components that have the same
functionality within a set of Web pages are identified consistently.
(Level AA)

It's safe to say that these SCs are the common practices in the web
design and "support the ability of both mainstream and specialized
user agents to adapt content to formats that meet their users' needs".

Proposed Change:
Move 3.2.4 to Level A.

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

We consider it good news that this success criterion describes common
practice in Web design, since it is very important to people with some
types of cognitive, learning, and language disabilities.

The success criterion's purpose is to support consistency in direct
access to content by people who use conventional user agents, rather
than providing additional support for alternate renderings via
assistive technology.  And it does place more limits on visual
presentation. For these reasons, we believe Level AA is the
appropriate level.
Received on Sunday, 4 November 2007 02:34:05 UTC

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