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

Dear JIS,

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: about "Accessibility Supported"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0317.html
(Issue ID: 2172)
----------------------------
Original Comment:
----------------------------

In the description of "Accessibility Supported" in the section of
"Important New Terms Used in WCAG 2.0", there is an Editorial Note
which reads "The W3C WAI will be compiling existing information on its
technologies. It is expected that other organizations will compile
such information for their technologies. There will undoubtedly be
others who create documented lists as well."

It is irresponsible of WCAG WG to rely on the "other organizations".
WCAG 2.0 is a guidelines which would be recommended by W3C/WAI. If
WCAG 2.0 require authors to consult documented lists of technologies
that are known to have accessibility support, WCAG 2.0 itself should
provide the documented lists.

If WCAG 2.0 would rely on other organizations, WCAG WG should create
the test files for each technologies so that other organizations will

be able to compile such information based on the same level of the
measure. The documented lists for any languages should be created by
using the same test files and the same test procedure with the same
measure. Without those materials, JIS WG or any other organization in
Japan won't be able to do anything. Even if some organization would
create the lists, it could be unreliable information and the sites
based on such information could be inaccessible to the users in
reality. For any other languages than English, this must be one of the
big concerns.

Additionaly, the format for the documented lists should be provided to
ensure the consistency across the languages.

Proposed Change:
- Develop and Provide the test files and the measure for the
documented lists on Accessibility Supported technologies.

- Provide the format for the documented lists.

- Not rely on the other organizations than W3C as WCAG 2.0 is one of
the W3C guidelines.

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

WCAG will be providing the format for a documented list.  We cannot
document all versions of all technologies for all languages by
ourselves however.  It is simply too much work and there are not
sufficient resources.  Also, it would not make sense to duplicate or
turn away good research by others.

It is beyond the WCAG WG charter to document all technologies, in
particular proprietary technologies that are not maintained by an open
standards body such as the W3C.  The Web Content Accessibility
Guidelines set guidelines to determine if a technology is
accessibility supported.

----------------------------------------------------------
Comment 2: Discussion of "Documented lists" needs clarification
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0318.html
(Issue ID: 2173)
----------------------------
Original Comment:
----------------------------

In the section of "Understanding Documented lists of Web technologies
with Accessibility Support", it reads "There is no requirement in WCAG
that a documented list be used or that technologies from such a list
be used."

It is confusing because it can also be read as "the authors don't need
to refer and/or use the documented lists when choosing the
technologies in order to conform to WCAG 2.0." Then the Documented
lists of Web technologies with Accessibility Support won't be needed
at all.

In the last paragraph within the same section, at the same time, it
reads "Authors, companies or others may wish to create and use their
own lists of accessibility-supported technologies." This is the
contradictory statements.

Proposed Change:
Add more clarification on what the documented lists are and for what
they are needed.

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

We have added a section "Understanding Documented Lists" to the
Understanding WCAG 2.0 document and provided a link from WCAG 2.0 to
this section.

We clarified this section as well.  It now reads:

Understanding Documented lists of Web technologies with Accessibility Support

Because individual authors will not usually be able to do all of the
research necessary to determine which features of which Web
technologies are actually supported by which versions of assistive
technologies and user agents, authors will usually rely on public
documented lists of Web technologies that document which assistive
technologies support which features of which Web technologies. By
public, we only mean that the list and its documentation are public.
Anyone can create a publicly documented list of "Web Technologies and
their Accessibility Support." People may create recommended
"documented lists of technologies" and give them a name (e.g. the XYZ
Accessibility Coalition's 2007 Supported Technologies List) that
authors can use. As long as they are publicly documented, authors or
customers etc. can easily select lists that meet their needs.
Customers or others can pick lists that fit their environment or
language at any point in time and specify those to be used in creating
their content. Authors are strongly encouraged to choose lists that
have an established reputation for accuracy and usefulness. Developers
are strongly encouraged to provide information about the accessibility
support for their technologies. The Working Group anticipates that
only lists that provide accurate information and benefit both authors
and users will achieve market recognition in the long term.

There is no requirement in WCAG that a public documented list be used
or that only technologies from such a list be used. The public
documented lists are described only as a method to make an otherwise
critical, but somewhat complicated, aspect of conformance easier for
authors who are not themselves experts on assistive technology support
(or who just don't have the time to keep up with advances in
mainstream and assistive technology support for each other).

Authors, companies or others may wish to create and use their own
lists of accessibility-supported technologies and this is allowed in
meeting WCAG. Customers, companies or others may however specify that
technologies from a custom or public list be used. See Appendix B
Documenting Accessibility Support for a Web Technology.

----------------------------------------------------------
Comment 3: What does "accessibility support" mean?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0319.html
(Issue ID: 2174)
----------------------------
Original Comment:
----------------------------

In the "Note 2" within the section of "Understanding Accessibility
Support", it reads "When a Web Technology is "accessibility
supported," it does not imply that the entire technology must be
supported. Most technologies lack support for at least one feature.
When referring to "accessibility support" for a technology, the
support for specific aspects, features, and extensions should be cited
if the technology as a whole is not accessibility supported. "

We couldn't understand what WCAG WG want to mean by this. It can also
be read as "if the one of the features for a technology is supported
by a assistive technology, the technology can be recognized as
accessibility supported". It could lead many conformant websites to be
inaccessible in the reality.

Proposed Change:
Add more understandable clarification.

Received on

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

We do not have any requirements for platforms per se, but the
description of accessibility support for a technology should note
which platforms the technology has AT support on.  This is described
in the section "Understanding Accessibility Support" in "Understanding
Conformance".

We have tried to make this clearer in the current version of
Understanding Conformance in Understanding WCAG 2.0, in the section
"Documenting Accessibility support for a Web Technology".

Most Web technologies have some aspects that are not supported.  So
complete support is rare if it occurs at all.  The description of
accessibility support will provide information on how much support is
provided for various features within technologies.  Decisions about
which features of technologies can be used (are accessibility
supported) can then be made based on these reports.

----------------------------------------------------------
Comment 4: Why "18 point or 14 point bold"?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0320.html
(Issue ID: 2175)
----------------------------
Original Comment:
----------------------------

It reads "18 point text or 14 point bold text is judged to be large
enough to require a lower contrast ratio." in the second paragraph of
the "Intent of this Success Criterion". But we couldn't understand the
reason why the working group judge that "18 point text or 14 point
bold text" is large enough to require a lower contrast ratio. Are
these sizes applied to the characters in any other languages such as
CJK languages? We need the rationale or the  ground on \"18 point text
or 14 point bold text" in order to determine if it would also make
sense in the Japanese characters.

Proposed Change:
Add the more concrete reason why "18 point text or 14 point bold text
is judged to be large enough to require a lower contrast ratio."

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

These numbers were worked out with assistance from the Lighthouse
International (http://lighthouse.org/) - an organization in the US
that does research on low vision. To handle other languages, we have
changed the note to read:

larger scale (text)
with at least 18 point or 14 point bold or font size that would yield
equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features
and characteristics that reduce the familiarity of their letter forms
are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does
not include resizing that may be done by a user.

Note 3: The actual size of the character that a user sees in dependent
both on the author-defined size and the users display or user-agent
settings. This success criterion is based on common pixel sizes
available today. Users who have low vision would be responsible for
choosing appropriate settings.

----------------------------------------------------------
Comment 5: Rationale for "200%" and 50%?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0321.html
(Issue ID: 2176)
----------------------------
Original Comment:
----------------------------

We need more concrete reason/rationale on why "200 percent" and "50
percent" were chosen by the WCAG WG. Without the reason/rationale, we
won't be able to determine if "200 percent" and "50 percent" can be
applied to the Japanese characters.

Proposed Change:
Add more concrete rationale for why "200%" and "50%".

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

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 6: How to measure dB(A) SPL and Tools
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0322.html
(Issue ID: 2177)
----------------------------
Original Comment:
----------------------------

There should be the instructions on how to measure the volume in dB(A)
SPL. It\'ll be helpful and useful if the working group could introduce
any tools for the authors to measure the volume.

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

- Add the links to the tools.

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

Same response as Issue 2113.

----------------------------------------------------------
Comment 7: Responsible for "200%" and 50%"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0323.html
(Issue ID: 2178)
----------------------------
Original Comment:
----------------------------

It can be read as "Authors have to provide a mechanism which allows
the users to resize text up to 200 percent and down to 50 percent.

If it is NOT what the WCAG WG wanted to say, the documents need more
clarification on this.

If it is what the WCAG WG wanted to say, the user agents should be
responsible for it.

Proposed Change:
Add the clarification on who should be responsible for "200%" and 50%"
and what the authors have to do.

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

This is explained in "Understanding SC 1.4.7":

See

The scaling of content is primarily a user agent responsibility.  User
agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure
text scale.  The author's responsibility is to create Web content that
does not prevent the user agent from scaling the content and that
allows the reflow of the content within the current width of the
viewport.

----------------------------------------------------------
Comment 8: Sound Volume Control
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0330.html
(Issue ID: 2185)
----------------------------
Original Comment:
----------------------------

In 1.4.2, now it reads "or a mechanism is available to control audio
volume which can be set independently of the system volume."

This seems to address our comment which said "Is it unnecessary for
WCAG 2.0 to require the mechanism of the audio volume control?" But
"Response from Working Group" seems to reject our sugestion.

Just to confirm. JIS WG still would like WCAG 2.0 to require the
mechanism of the audio volume control.

Most media players already have volume controls on them. However most
of their interfaces can also be customized by the developers and the
volume controls can be hidden in such customized skins of the media
players. Aadditionally the authors can create the original interfaces
without the volume controls, for example, by using Flash [1],[2].

Having stop button is not necessarily sufficient since the volume can
be too loud. In this case, it is not an user agent issue but a web
content issue which is under the authors' control.

For the customized interface without the volume controls on them, is
it still unnecessary for WCAG 2.0 to require the mechanism of the
audio volume control?

We just want to confirm that "or a mechanism is available to control
audio volume which can be set independently of the system volume." in
1.4.2 addresses our concern or not.

[1] http://www.jvcmusic.co.jp/tarako/

[2] http://www.kewpie.co.jp/tarako/

----------------------------------------------------------

Comment 9:

Source: http://www.w3.org/mid/20060623095914.FE78.NABE@lab.twcu.ac.jp
(Issue ID: LC-1322)

Comment: JIS X 8341-3 also addresses the importance of volume control.
It allows the users who are hard of hearing to adjust the volume of
the audio. Is it unnecessary for WCAG 2.0 to require the mechanism of
the audio volume control?

JIS 5.7 b) says:

b) Sound should be controllable by users.

Information:

Hearing impaired users cannot detect that sound is being played. Also,
there are cases where louder volume is preferred.

Example:

To enable users to adjust volume, play, and stop, provides controls
for play, stop, and volume adjustment. When using plugins, they can be
used for this purpose

----------------------------

Response from Working Group:

----------------------------

Control of volume is a user agent issue. Most players already have
volume controls on them.  Content, due to security issues, usually
cannot directly access the hardware volume control and thus can
onlyturn volume down not up.   We therefore do not include a
recommendation for content to also include a volume control, though
user agents should. This belongs to the domain of User Agents and is
covered in the User Agent guidelines (UAAG 1.0) which reads as
follows:

"Guideline 4. Ensure user control of rendering...User agents rendering
audio have to allow the user to control the audio volume globally and
to allow the user to control distinguishable audio tracks."

Proposed Change:
Response from Working Group said "Control of volume is a user agent issue."

But 1.4.2 reads "or a mechanism is available to control audio volume
which can be set independently of the system volume."

Need more clarification on this issue.

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

Yes, the situation that you describe is covered by SC 1.4.2. The
author is responsible for making sure that there is some mechanism for
the user to control the sound. Often, the mechanism is provided by the
default behavior of the user agent. In this example, because the media
player has been customized, the volume controls on the media player
are not available to the user, so the author cannot rely on the
default user agent-provided mechanism to satisfy SC 1.4.2. The author
would need to provide some other mechanism.

To make it clearer what is meant by controlling the volume, we have
also reworded it as follows:

1.4.2 Audio Turnoff: If any audio plays automatically for more than 3
seconds, either a mechanism is available to pause or stop the audio,
or a mechanism is available to control audio volume which can be set
to a different level from the system volume level. (Level A)

Received on Sunday, 4 November 2007 04:49:00 UTC