- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:41:44 -0700
- To: "Masafumi Nakane" <max@wide.ad.jp>
- Cc: public-comments-WCAG20@w3.org
Dear Masafumi Nakane ,
Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.
We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.
This message contains the comments you submitted and the 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 updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.
PLEASE REVIEW the decisions for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.
We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.
Thank you,
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:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1220)
The concept of baselines can greatly improve the flexibility of how
authors produce Web content. However, this is true only if appropriate
and realistic baselines for the community which the content is
targeted can be specified without much difficulty. While this may not
be an issue in countries where population of assistive technology
users is not so small and there are more than a few accessibility
experts, this will be an issue in many places where assistive
technologies are not widely deployed or advanced. Therefore, WAI (or
W3C) should do its best to encourage important, and trusted players in
various communities, such as different disability communities in
different countries, to help build typical and reasonable baselines.
Otherwise, the baseline concept may be misunderstood and misused, and
many conforming, but inaccessible content could be produced.
----------------------------
Response from Working Group:
----------------------------
The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section "
Accessibility Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
WAI definitely encourages knowledgeable players in various communities
to evaluate user agent and assistive technology support and determine
what technologies are accessibility-supported content technologies for
their community. Making this information available to authors would be
an extremely important step towards accessible content.
----------------------------------------------------------
Comment 2:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1221)
Specifying baselines in terms of Web technologies in stead of browsers
is reasonable and understandable technically, however, is not
realistic.When an author specifies HTML 4.01 and CSS Level 2 in the
baseline, for example, that could mean the content can include some
HTML elements and/or CSS properties that are not supported by any of
existing browsers and still being WCAG compliant. There should be a
mechanism to specify the baseline in more detailed manner, probably a
way to refer to particular set of functionalities of the technologies
in question.
----------------------------
Response from Working Group:
----------------------------
The term "baseline" has been replaced by "accessibility-supported Web
technologies". So we would now talk about whether a technology was
accessibility supported, instead of whether or not it was in the
baseline.
Content must still satisfy the success criteria. The descriptions of
the sufficient techniques for different technologies include a section
for User Agent Notes. This is where a developer can find information
about different User Agents that may not support the technique
properly.
When documenting support for "Accessibility Supported Web
Technologies", user agent support, including assistive technology
support, would definitely be examined and documented. This would be a
good place to record limitations in the support for different
features. This would provide a more complex description of the
accessibility support for the technology.
----------------------------------------------------------
Comment 3:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1222)
Will these examples conform to WCAG? 1. A perfectly conforming
blogsite, with comment form, and comments posted by someone breaks the
conformance; 2. The page is perfectly conforming, except for a
fragment of code which was provided by affiliate program of a shopping
site, and the user is not allowed to modify the code either for
technical reasons or for legal reasons. From the current wording of
WCAG, these examples look to be not conforming to WCAG. This can limit
the creativity and variety in ideas for Web content if authors are
keen to meet the WCAG, or else, let many authors decide not to care
too much about the conformance.
Proposed Change:
Limit the responsibility of the content creator to those Web units
that are authored by the creators themselves.
----------------------------
Response from Working Group:
----------------------------
We have rewritten the conformance section to clarify that WCAG is
descriptive rather than prescriptive. That is, it doesn't say what
should be accessible. Rather, it is a measure of accessibility. The
conformances section has been rewritten to reflect this. We have
removed all language about 'exceptions' so that conformance simply
describes which pages conform to the Success Criteria.
We have also included an ability for authors to make a statement of
partial conformance that they can use to describe the parts of a page
don't or might not conform.
We have clarified the situation by removing all exceptions and adding
the following at the end of the conformance section:
Note: If pages can not conform (for example, conformance test pages or
example pages) they would not be included in the conformance claim.
Statement of partial conformance
Sometimes, Web pages are created that will later have additional
content added to them. For example, an email program, a blog, or an
article that allows users to add comments to the bottom. Another
example would be a company or individual who compiles a page from
multiple sources. Sometimes, the content from the other sources is
automatically inserted into the page over time.
In both of these cases, it is not possible to know at the time of
original posting what the content of the pages will be. Two options
are available:
1. A conformance claim is made based on best knowledge. If a page of
this type is monitored and kept conformant (non-conforming content is
immediately removed or made conforming) then a conformance claim can
be made since, except for error periods, the page is conformant. No
conformance claim should be made if it is not possible to monitor or
correct non-conforming content.
2. A "statement of partial conformance" is made. A statement that the
page does not conform, but could conform if certain parts were removed
can be made. The form of that statement would be, "This page would
conform to WCAG 2.0 at level X if the following parts from
uncontrolled sources were removed."
1. This "statement of partial conformance" cannot be used for content
that is under the author's control.
2. The "following parts" of the page that would need to be removed
would be described in terms that users can understand. (e.g. they
can't be described as "all parts that we do not have control of"
unless they are clearly marked as such.)
----------------------------------------------------------
Comment 4:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1223)
This seems to consist of 1.2.3 and 1.2.7. This structure, where
meeting one success criterion automatically means meeting another, is
rather confusing.
Proposed Change:
Add a clear explanation of relationship among related SCs, either in
the WCAG or in the UW.
----------------------------
Response from Working Group:
----------------------------
The success criteria are written as clearly as we know how. There are
only two general techniques for making multimedia accessible to the
blind: Audio Description (AD) and Full Text Alternatives. Either
technique is acceptable for Level A WCAG 2.0 conformance. Audio
Description is required for Level AA. Both techniques are required
for Level AAA. This is a case where higher-level success criteria
build upon the requirements of lower-level success criteria with the
intention of having cumulative, progressively stronger, requirements.
----------------------------------------------------------
Comment 5:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1224)
Some multimedia content is accessible even without audio description.
They can be understood without any problem from the background sounds,
narration, etc. Setting this success criterion to be level 1 or 2 can
cause redundancy the information provided in audio, and may hinder the
accessibility of such simple content.
Proposed Change:
Make this applicable only to those content that cannot be understood
without audio description. There may be a discussion how to determine
if piece of content is accessible without audio description, but that
should be as easy as determining if added audio description
insufficient to make the content accessible.
----------------------------
Response from Working Group:
----------------------------
If the audio track provides full information about the video (as in
your example) then it is accessible already and no Audio Description
would be necessary. We have added a note to G78: Providing a sound
track that includes audio description that describes this exception.
----------------------------------------------------------
Comment 6:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1225)
Is there any scientific fact that supports luminosity contrast ration
of5:1 is sufficient? Unless this is a scientifically proven ration and
isn't likely to be changed in future, such a value should not be
included in a normative part of the document.
----------------------------
Response from Working Group:
----------------------------
The 5:1 contrast ratio provides a minimum contrast of around 3:1 for
the major types of color blindness. A contrast ratio of 3:1 is the
minimum level recommended by ANSI/HFS 100-1988. 10:1 provides
approximately 7:1 contrast ratio for individuals with color blindness,
which is the recommended contrast level in ANSI/HFS 100-1988.
We have added the following to the Intent sections of SC 1.4.1 and 1.4.4:
The 5:1 contrast ratio provides a minimum contrast of around 3:1 for
the major types of color blindness. A contrast ratio of 3:1 is the
minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988].
Calculations in ISO 9241-3 and ANSI/HFS 100-1988 are for body text. A
relaxed contrast ratio is provided for text that is much larger (twice
as tall and with three time the thickness of lines in the character).
Notes on formula
Conversion from nonlinear to linear RGB values is based on IEC/4WD
61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the
Internet - sRGB" [sRGB].
The formula (L1/L2) for contrast is based on ISO 9241-3 and ANSI/HFS
100-1988 standards.
The ANSI/HFS 100-1988 standard calls for the contribution from ambient
light to be included in the calculation of L1 and L2. The .05 value
used is based on Typical Viewing Flare from IEC/4WD 61966-2-1 and the
sRGB paper by M. Stokes et al.
This success criterion and its definitions uses the terms contrast
ratio and relative luminance rather than luminance to reflect the fact
that Web content does not emit light itself. The contrast ratio gives
a measure of the relative luminance that would result when displayed.
(Because it is a ratio, it is dimensionless.)
Note: Refer to related resources for a list of tools that utilize the
contrast ratio to analyze the contrast of Web content.
----------------------------------------------------------
Comment 7:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1226)
Is there any scientific fact that supports luminosity contrast ration
of10:1 is sufficient? Unless this is a scientifically proven ration
and isn't likely to be changed in future, such a value should not be
included in a normative part of the document.
----------------------------
Response from Working Group:
----------------------------
The 10:1 contrast ratio provides a minimum contrast of around 7:1 for
the major types of color blindness. A contrast ratio of 7:1 is
recommended by [ANSI-HFES-100-1988].
We have added the following to the Intent sections of SC 1.4.1 and 1.4.4:
Calculations in ISO 9241-3 and ANSI/HFS 100-1988 are for body text. A
relaxed contrast ratio is provided for text that is much larger (twice
as tall and with three time the thickness of lines in the character).
Notes on formula
Conversion from nonlinear to linear RGB values is based on IEC/4WD
61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the
Internet - sRGB" [sRGB].
The formula (L1/L2) for contrast is based on ISO 9241-3 and ANSI/HFS
100-1988 standards.
The ANSI/HFS 100-1988 standard calls for the contribution from ambient
light to be included in the calculation of L1 and L2. The .05 value
used is based on Typical Viewing Flare from IEC/4WD 61966-2-1 and the
sRGB paper by M. Stokes et al.
This success criterion and its definitions uses the terms contrast
ratio and relative luminance rather than luminance to reflect the fact
that Web content does not emit light itself. The contrast ratio gives
a measure of the relative luminance that would result when displayed.
(Because it is a ratio, it is dimensionless.)
Note: Refer to related resources for a list of tools that utilize the
contrast ratio to analyze the contrast of Web content.
----------------------------------------------------------
Comment 8:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1227)
This structure, where meeting 1.4.3 automatically means meeting 1.4.1
is rather confusing.
Proposed Change:
Add a clear explanation of relationship among related SCs, either in
the WCAG or in the UW.
----------------------------
Response from Working Group:
----------------------------
We have tried to use the same format thoughout the guidelines so that
it is clear that Level AAA may provide success criteria that require
more accessibility than Level A. Here, the 10:1 luminosity contrast
ratio at Level AAA is a stricter requirement than a 5:1 luminosity
contrast ratio at Level AA. It should be clear that satisfying SC
1.4.3 satisfies SC 1.4.1. This is consistent with other WCAG 2.0
success criteria where Level AA and Level AAA success criteria are
progressively more restrictive than Level A success criteria within
the same guideline. For example, see SC 2.1.2 and 2.1.1.
----------------------------------------------------------
Comment 9:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1228)
Is there any scientific fact that supports 20db is sufficient? Unless
this is a scientifically proven value and is not likely to be changed
in future, such a value should not be included in a normative part of
the document.
----------------------------
Response from Working Group:
----------------------------
There are a number of studies that this is based on. One is the
Report done for the Access Board in 1999. In that study, 75% of the
subjects needed a S/N of 18 dB to be minimally acceptable.
http://www.hearingresearch.org/Pubs/Access_Bd_Final_Report.pdf
The most recent is Interference in Hearing Aids from Digital Wireless
Telephones by Levitt, Kozma-Spytek, and Harkins in Seminars in
Hearing/Volume 26, Number 2, 2005. It found that a signal to noise
ratio of 32 to 28 db was needed for 90% to find phones highly usable,
24 to 20 db for 90% to for minor limitation on use and 15 to 12 db for
Major Limitation of use.
----------------------------------------------------------
Comment 10:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1229)
Today, there are two levels of "being keyboard operable." One is
simply being able to operated without using a mouse, with simple
keystrokes such as the tab and the enter keys. The other, higher level
is where author uses extensive client-side scripting to provide
keyboard shortcuts. (The user interface of the Gail is an example.) In
the latter case, many of the keystrokes provided by the author may
conflict with keyboard commands provided by the UA (including the
assistive technology.) Thus, in this case, it would not make much
accessibility improvement especially for those using screen readers
and other AT that make extensive use of keyboard. Explanation in the
WCAG and the Subdocument should be clearer about this point.
----------------------------
Response from Working Group:
----------------------------
This isn't something that would be handled in the guidelines
themselves. This type of topic would be handled in an application
notes. We would love to write an Application Note "Enhancing Keyboard
Access to Web Content" that would provide guidance on assigning
hotkeys, defining logical tab order, defining hotkeys shown on
buttons, and defining tab indices for text focus and search
functionality. It might also discuss the topic of "number of
keystrokes to perform the equivalent of one mouse action" but it won't
be able to define "comparable access" since it would differ so much
based on individual abilities to point or create keystrokes. User
agent support for access keys is so bad that developers have started
looking for server-side solutions that allow users to define access
keys (see http://juicystudio.com/article/user-defined-accesskeys.php
and http://juicystudio.com/article/user-defined-access-keys-aspversion.php).
If you are aware of a good paper or application note on this we would
be most interested.
----------------------------------------------------------
Comment 11:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1230)
Is there any scientific fact that supports the figures given in this
success criterion (10 times, 20 seconds) are sufficient? Unless these
are scientifically proven values and are not likely to be changed in
future, such values should not be included in a normative part of the
document.
CLARIFICATION FROM Makoto Ueki: Nakane-san wanted to say that WG
should explain the reason why the number is chosen more clearly in the
documents. If WG doesn't do that, for example, a web developer only
can say "WCAG 2.0 says so." to the client. He doesn't want the number
to be removed.
----------------------------
Response from Working Group:
----------------------------
It is not clear what you mean by scientific fact. There is no number
that is sufficient for all users. For some individuals, these values
would not be enough. For others, they are. Still others do not need
values this high. Removal of the numbers would make the success
criterion untestable, so that is not an option. In the opinion of
those on the working group and those consulted who work with
populations with timing problems, these figures are sufficient to
cover most users and the numbers harmonize with other accessibility
standards efforts.
The following text has been added to the "how to meet" document for
2.2.1 to provide more information on the numbers used.
* 10 times the default was chosen based on clinical experience and
other guidelines. For example, if 15 seconds is allowed for a user to
respond and hit a switch, 150 seconds would be sufficient to allow
almost all users to hit a switch even if they had trouble.
* 20 seconds was also based on clinical experience and other
guidelines. 20 seconds to hit 'any switch' is sufficient for almost
all users including those with spasticity. Some would fail, but some
would fail all lengths of time. A reasonable period for requesting
more time is required since an arbitrarily long time can provide
security risks to all users, including those with disabilities, for
some applications. For example, with kiosks or terminals that are
used for financial transactions, it is quite common for people to walk
away without signing off. This leaves them vulnerable to those walking
up behind them. Providing a long period of inactivity before asking,
and then providing a long period for the person to indicate that they
are present can leave terminals open for abuse. If there is no
activity the system should ask if the user is there. It should then
ask for an indication that a person is there ('hit any key') and then
wait long enough for almost anyone to respond. For "hit any key" 20
seconds would meet this. If the person indicates that they are still
present, the device should return the user to the exact condition that
existed before it asked the question.
----------------------------------------------------------
Comment 12:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1231)
Is there any scientific fact that supports 3 seconds is sufficient?
Unless this is a scientifically proven value and is not likely to be
changed in future, such a value should not be included in a normative
part of the document.
----------------------------
Response from Working Group:
----------------------------
This guideline is designed to prevent people with attention deficit
disorders from being unable to access a page because of blinking text.
However being able to use blinking to draw attention to important
information is helpful to many people including people with cognitive
disabilities. The three seconds was selected as a testable length of
time that was long enough to attract attention, but not too long a
time for people to wait it out.
----------------------------------------------------------
Comment 13:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1232)
While 2.3.1 is written using the terms "general flash threshold" and"
red flash threshold", this success criterion is written with a
specific number. Since the UW document is informative, and those
values can be changed if needed, this way of writing could cause
future inconsistency. If there is any possibility of these values to
be changed in future, the specific values should not be mentioned in a
normative part of the document.
----------------------------
Response from Working Group:
----------------------------
This number is based on extensive research by multiple researchers.
The number comes from existing broadcast standards. This success
criterion addresses the problem of consumer that might enlarge parts
of the screen. By satisfying this success criterion, users can meet
accepted guidelines for avoiding photosensitive seizures even if they
enlarge flashing areas of the screen. These numbers are based on
human physiology (not technology) so it is unlikely that these numbers
will change.
----------------------------------------------------------
Comment 14:
Source: http://www.w3.org/mid/86sllxu78d.wl%max@wide.ad.jp
(Issue ID: LC-1233)
When a Web unit is not valid, or not conforming to a specification,
how can one be sure if the Web unit is able to be parsed
unambiguously?
----------------------------
Response from Working Group:
----------------------------
To make this requirement easier to understand, we have reworded SC
4.1.1 as follows:
Content implemented using markup languages has elements with complete
start and end tags, except as allowed by their specifications, and are
nested according to their specifications.
Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.
The working group looked at this topic carefully over an extended
period of time and concluded that requiring strict adherence to all
aspects of specifications does not necessarily result in an increase
in accessibility. For example, it is possible to create invalid pages
that present no accessibility barriers. It is also possible in certain
situations to enhance accessibility through the use of markup that is
not part of the specification.
The working group must work within its charter and only include things
that directly affected accessibility. Some aspects of "use
technologies according to specification" and validity do relate to
accessibility. However, others do not. So requiring validity would
take us beyond our charter. We do recommend it though and it is our #1
technique listed for conforming to SC 4.1.1.
Received on Thursday, 17 May 2007 23:42:10 UTC