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

Dear Jason White,

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: Consider extending this to cover the auditory presentation
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0143.html
(Issue ID: 1939)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 1.3.3
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

Should this be extended to include auditory presentation, e.g., the
sound of the content as presented in, for example, VoiceXML?

Such an extension would surely be of benefit to people who are deaf in
accessing Web-based voice/sound applications and similar content. For
example, instructions such as \"The selected items are read in a male
voice; unselected items are read in a female voice\" are unhelpful,
even if the distinction between selected/unselected items in the user
interface can be programmatically determined.

Proposed Change:

Consider extending this to cover the auditory presentation (i.e.,
sound) of the content.

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

We agree that audio is an important sensory modality that needs to be
captured, and others need not be left out.  We have adjusted the
provision as follows:

1.3.3 Sensory Characteristics: Instructions provided for understanding
and operating content do not rely solely on sensory characteristics of
components such as shape, size, visual location, orientation or sound.
(Level A)

----------------------------------------------------------
Comment 2: Problems with CAPTCHA Clause
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0142.html
(Issue ID: 1940)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 1.1.1
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

CAPTCHA: This success criterion is problematic. Even if both auditory
and visual forms are provided, the content will remain inaccessible to
users who are deaf blind. Furthermore, this lack of accessibility is
not remedied at either level AA or level AAA of guideline 1.1, there
being no success criteria at those levels.

Cognitive CAPTCHA, e.g., arithmetic problems, can overcome the sensory
difficulty noted above, while running the risk of raising barriers to
people with cognitive disabilities.

The only solution is to abandon CAPTCHA altogether, in favour of statistical
filtering, e-mail confirmation or other security techniques as the
situation demands. Given that services subject to CAPTCHA are often,
from a practical point of view, significant, the result of the
unfortunate compromise in guideline 1.1 is to exclude a significant
group of users - those who are deaf blind - from important Web
content.

Proposed Change:

Either require cognitive CAPTCHA, noting that it must be designed so
as to minimize its adverse effect on users with cognitive
disabilities, or, preferably, acknowledge that the CAPTCHA phenomenon
is incompatible with accessibility, and hence incompatible with WCAG
2.0 conformance.

While a Level AA success criterion excluding sensory CAPTCHA would be
a welcome improvement to the current situation, it would still leave
Level A-conformant content inaccessible to a significant group of
users. Depending on the interpretation of WCAG 1.0, checkpoint 1.1,
the current WCAG 2.0 draft is arguably a regression in that it offers
less accessibility than is guaranteed by the 1.0 guidelines at level
A, where no such limitation is admitted.

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

The Working Group recognizes that CAPTCHAs create a significant
barrier, and requiring only two alternate modalities will exclude some
users. The WG believes, however, that this requirement strikes the
best balance between benefit to users and achievability for authors.
Recognizing that there are further steps possible and that authors
need to be informed of the situation, we have added a note to
Understanding 1.1.1 explaining the situation and providing additional
recommendations, which authors are strongly encouraged to follow.

----------------------------------------------------------
Comment 3: when can an author assume a mechnism is available?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0144.html
(Issue ID: 1941)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 1.4.2
Part of Item:
Comment Type: question
Comment (Including rationale for any proposed change):
The definition of "mechanism", correctly in my opinion, makes it clear that a
mechanism can be provided by user agents. It need not be provided by the author.

Under what circumstances is an author entitled to assume that a
mechanism to turn off the audio, or to regulate the volume, is
available, assuming that it is not required to be implemented by any
of the technologies included in the list of accessibility-supported
Web technologies referred to in the author's WCAG 2.0 conformance
claim?

Note that control over the rendering of audio is required by UAAG 1.0
guidelines 3 and 4. Thus, if the author wants to assume that this is
available, should this be achieved by including UAAG 1.0 in the list
of accessibility-supported Web technologies, effectively specifying
that a UAAG-conformant user agent is required in order for the content
to meet WCAG 2.0?

Proposed Change:

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

Whether the use of a user-agent-provided mechanism is a sufficient
technique will depend upon the accessibility support analysis for the
technology in question. User agent notes for techniques reflect the
working group's understanding of problems in support for the technique
in different user agents.

When the mechanism is not available in all user agents, the author
must determine whether the user agents used by or available to his
users all contain the appropriate support. If they do not, the
mechanism cannot be relied upon.
UAAG 1.0 would never be a candidate to be an accessibility-supported
technology, since it is not a web content technology but a set of
requirements on user agents. That is, one never "authors content in"
UAAG 1.0.

As more user agents satisfy UAAG 1.0, it should become easier for
authors to comply with WCAG, since user agents will provide more the
support needed for accessibility. However, authors cannot assume UAAG
compliance, but must check the actual functionality of user agents
used by or available to their users.

----------------------------------------------------------
Comment 4: Make it clear somewhere in the guidelines (perhaps the
conformance section) that UI standards such as UAAG can be AsCT
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0147.html
(Issue ID: 1942)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 2.4.1
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

The same problem that I raised regarding the availability of a
"mechanism" in connection with sc 1.4.2 also arises here.

If user agents support UAAG 1.0 structural navigation requirements
then this sc (2.4.1) can be satisfied by providing proper structure in
the content. However, given the wording of the
"accessibility-supported Web technology" provisions in the Conformance
section, it is far from clear that UAAG 1.0 can be specified in a
published list of saccessibility-supported Web technologies, within
the meaning of the WCAG 2.0 conformance requirements.

Proposed Change:

Make it clear somewhere in the guidelines (perhaps the conformance
section) that user interface standards such as UAAG 1.0 can appear in
published lists of accessibility-supported Web technologies, and that
such lists are not limited to the technologies in which content is
represented.

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

Whether the use of a user-agent-provided mechanism is a sufficient
technique will depend upon the accessibility support analysis for the
technology in question. User agent notes for techniques reflect the
working group's understanding of problems in support for the technique
in different user agents.

When the mechanism is not available in all user agents, the author
must determine whether the user agents used by or available to his
users all contain the appropriate support. If they do not, the
mechanism cannot be relied upon.
UAAG 1.0 would never be a candidate to be an accessibility-supported
technology, since it is not a web content technology but a set of
requirements on user agents. That is, one never "authors content in"
UAAG 1.0.

As more user agents satisfy UAAG 1.0, it should become easier for
authors to comply with WCAG, since user agents will provide more the
support needed for accessibility. However, authors cannot assume UAAG
compliance, but must check the actual functionality of user agents
used by or available to their users.

----------------------------------------------------------
Comment 5: Should this be applied to everything that qualifies as a "Web page"?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0148.html
(Issue ID: 1943)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 2.4.2
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

Are you sure this can be applied, and ought to be applied, to
everything that qualifies as a "Web page" under the definition?

For example, how would this be applied to a multimedia object? A title
could be included in the captions, but it isn't clear that captions
count for purposes of satisfying this success criterion. Would the
title have to be both presented as part of the multimedia and audio
described or captioned? If I place a sound file on my Web site, it can
qualify as a "Web page" under the definition, but it isn't obvious
that I can meet this success criterion. If the sound file can include
metadata, then perhaps providing a title in metadata would be adequate
- but does this imply that audio formats that don't allow for metadata
can't be used as part of a fully-conformant site? The same question
arises in relation to images, which also qualify as Web pages if they
are only linked to, not embedded as part of other resources.

Even if metadata can be embedded in the sound/image file, there is no
guarantee that the user can read it unless the specification of the
format requires user agents to be able to display the metadata.

It would appear that any interactive content providing a user
interface can satisfy this success criterion by including a title as
part of the user interface.

Proposed Change:

Perhaps this sc should be restricted to Web pages containing text,
where "text" does not include images of text. This would also admit
HTML pages containing only images, unless the presence of a text
equivalent (under guideline 1.1) is sufficient to make the page
"contain text" for the purpose of this proposal.

Restricting this sc to cases where the technology specifically
provides for the inclusion of titles (e.g., TITLE elements or
equivalents) wouldn't work, as there are surely cases in which the
technology doesn't provide for the identification of text as a title,
but where it is still possible and desirable to provide a title.

I suspect that this sc cannot remain at level A without restricting it
to a subset of Web pages.

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

The new guidelines allow items like this to be Web Pages as long as
there is a Conforming Alternate Version. Therefore there are two ways
to address these situations.
   1) to embed the resource in a Web page that can conform
   2) provide a 'conforming alternative version'

Thus the working group believes it can and should remain at level A.

----------------------------------------------------------
Comment 6: Add requirements for live audio-only or live video-only content
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0149.html
(Issue ID: 1944)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Guideline 1.2: Provide synchronized alternatives for multimedia
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

The definition of "multimedia" correctly provides that multimedia
content must be audio or video, synchronized with another format or
involving time-based interaction. Audio-only and video-only content
are not multimedia.

Under sc 1.1.1, live audio-only and video-only content is required to
be identified with a text equivalent. However, nowhere in guideline
1.1 or guideline 1.2 is it required to be accompanied by a text
transcript, at any level of conformance; and pre-recorded audio-only
and video-only content (not being multimedia) appear to escape
coverage altogether.

Thus, a radio station for example that provides transcripts of some of
its content (and such transcripts do exist) isn\'t achieving a
superior level of accessibility under WCAG than a radio station which
does not provide such transcripts.

Proposed Change:

Under guideline 1.1 or guideline 1.2, at different conformance levels
if necessary, provide for transcripts of both live and pre-recorded
audio-only and video-only content.

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

Response to Reviewer:

Prerecorded audio-only and prerecorded video-only is covered by SC
1.1.1. Since it is not listed as one of the situations with special
handling, there must be a text equivalent that presents equivalent
information. Examples 2 and 3 of Examples of Success Criterion 1.1.1
demonstrate text equivalents for some audio-only and some video-only
content.

Because it is so difficult to provide text alternatives that convey
the same information as live audio-only and live video-only content,
only a descriptive label is required at Level A. We are aware of no
techniques for providing text alternatives for live video-only
content. We will be adding a technique for live audio-only content.

----------------------------------------------------------
Comment 7: Define "programmatically determined link context" more precisely
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0150.html
(Issue ID: 1945)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):
It isn't clear from the sc or the definition of "programmatically
determined link context" how far around the link this context extends.
If it is bounded by the next higher-level structural component of the
content (e.g., the parent element of the link in the structure tree)
then it is a different requirement than it would be under an
interpretation, at the opposite end of the spectrum, whereby the whole
page can qualify as the link context. The latter interpretation would
tend to make the requirement trivial.

Without a clearer specification of what the link context encompasses,
it is difficult to evaluate the importance of this success criterion
or to decide how much of an accessibility issue it presents. For
instance, if the purpose of a link cannot be determined from a large
portion of the page then that would be more of a difficulty to users
than if it cannot be determined from the immediately enclosing
structural element.

Further, contrary to the suggestion in the editorial note, I don't
think this issue should be characterized as presenting a problem for
assistive technologies. Rather, it presents a problem to users as it
determines how much associated context they have to read in order to
discover the purpose or destination of a link.

Proposed Change:

Define "programmatically determined link context" in a more precise,
testable way, before deciding on the priority of this success
criterion.

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

While the guidelines do not specify the scope of relationships to a
link, relationships are defined to be meaningful, and the entire page
would not meet that test. The Understanding SC 2.4.4 document explains
that description of the link should be in the same sentence,
paragraph, list item, or table cell as the link because these are
directly associated with the link itself. This is based on the
features of current user agents and is expected to evolve.

----------------------------------------------------------
Comment 8: Technologies that do not permit alternate versions
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0155.html
(Issue ID: 1946)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Conformance
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

The editorial note to conformance requirement 4 points out the
difficulty that can arise with technologies which do not permit this
requirement to be satisfied. Limitations regarding an author\'s
content or server that can be removed by changing server-side
configurations or altering content should not be regarded as
constraints that prevent the implementation of this requirement
however, as these can all be overcome (in the second case by changing
the design of the content and in the first case by securing the
cooperation of the server operator, if the server operator is not the
author of the content).

With these remarks having been made, however, there remains the
possibility that a given technology, or combination of technologies,
in which a Web page is written may not provide the necessary mechanism
to meet requirement 4. This possibility is addressed in the following
proposal.

Proposed Change:

If it turns out that some technologies do not permit requirement 4 to
be met, then split the requirement into two alternative cases.

Case 1: Where the technologies used to implement the non-conforming
content support the provision of such a mechanism, stipulate that a
mechanism of the kind stated in Requirement 4 as currently drafted,
must be provided.

Case 2: where requirement 4 as currently proposed cannot be met,
specify the following weaker requirement:

The non-conforming page is part of a set of Web pages, at least one of
which provides a mechanism to obtain an alternate, conformant version.

Obviously, this mechanism would itself have to satisfy conformance
requirements, and the wording currently used to describe the mechanism
captures this intent perfectly, and should be carried over into any
revised draft. Note that the term "set of Web pages" is already
defined in the glossary and used elsewhere in the guidelines, and thus
can be employed here without introducing any new terminology or
concepts.

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

We have addressed the issue but not in the way you proposed.  One of
the key requirements is that people be able to find the conforming
version from the inaccessible version.  If the page will not support a
link to the conforming version then it won't support a link to the
other pages in the set, so if a person landed on the non-conforming
page there would be no way to find the set of pages or the alternate
conforming page.

Instead, we simply require that their be either a conforming link or
that there be some mechanism that is accessibility supported, which
would allow the person to find the conforming page from the
non-conforming page.

----------------------------------------------------------
Comment 9: Replace "forms" with "Web pages"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0151.html
(Issue ID: 1947)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Success Criterion 3.3.3
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):

This criterion should apply not only to "forms" (as in HTML forms or XForms)
but also to other user interface technologies which, while not forms
as such, nevertheless can be used to carry out transactions of the
relevant kind. For instance, it should not be open for an author to
argue that, because the content is implemented in an applet (or some
other technology) rather than as HTML forms or XForms, the success
criterion doesn't apply.

Proposed Change:

Replace "forms" with "Web pages".

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

We have accepted your proposal and have changed "forms" to "Web pages"
in 3.3.3 and 3.3.6 to avoid confusion with technology-specific uses of
the word "form."

----------------------------------------------------------
Comment 10: clarify "is not embedded in another resource"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0157.html
(Issue ID: 1948)
----------------------------
Original Comment:
----------------------------

Document: W2
Item Number: Appendix A: Glossary
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):
In the definition of "Web page" the phrase "is not embedded in another
resource" needs to be clarified.

Consider for example an image, which (as is typically the case) has
its own URI. It can be used in two ways: (1) by being embedded in,
i.e., rendered together with, another resource. In this case it is not
a Web page. (2) It can be linked to, or returned as the result of a
user interface action, without being embedded in anything else. In
this case it is a Web page by definition.

What determines whether it counts as a Web page or not is how it is used.

The ambiguity lies in the failure to specify what should be taken into
account in ascertaining how a resource is used for the purpose of
applying the definition. This has conformance-related consequences.
Suppose for example that, on your Web site, a particular image is
embedded in an XHTML document (using the IMG element or the SRC
attribute of XHTML 2.0). For purposes of your conformance claim, it is
embedded in another resource, and hence not a Web page. Assume further
that on my Web site, the same image (at the same URI) is referenced,
but only as a link, and is therefore not embedded in another resource.

If we interpret the "not embedded in another resource" requirement as
meaning "not embedded in another resource anywhere on the Web" then
for purposes of the conformance claim covering my Web site, the image
is not a distinct "Web page". However, if we interpret "not embedded
in another resource" as applying only to a "set of Web pages" as
defined in WCAG 2.0, then it appears that the image is a Web page for
purposes of my conformance claim (because it's never embeded in any of
my content), but is not a Web page for purposes of your conformance
claim (as it is embedded in one of your other resources). Under this
interpretation, it appears that my Web site will have conformance
difficulties, if the image format does not support the inclusion of
text alternatives, titles, etc., and the image thus cannot conform to
WCAG 2.0 as an independent entity. The same problem arises if the
image format does support text alternatives but you haven't supplied
one in the image itself, whereas (let's assume) you have supplied one
as part of the page in which the image is embedded. In both cases, the
image is a "Web page" for purposes of my content, but not for purposes
of yours, and my Web site as a whole doesn't conform to WCAG 2.0.

However, if WCAG were to adopt the first interpretation mentioned
above, whereby a resource is "not embedded in another resource" only
when it is not so embedded anywhere whatsoever, then it appears that
the conformance attained by my Web site, given the above scenario, now
depends on whether anybody else's Web site embeds the image in another
resource. Hence, the conformance of my site depends on other peoples'
actions, totally unrelated to my content, and this doesn't seem
satisfactory either.

Proposed Change:

I haven't thought of a good solution, since as shown above, both of
the obvious answers have problems.

Moreover, the kind of scenario that results in this difficulty could
actually occur in practice: all that needs to happen for example is
for one Web site to link directly to an image (or other embeddable
resource) on another site, instead of linking to the page of the other
site in which it is embedded.

Follow up (from
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0158.html)

This is a follow-up regarding my earlier comment concerning "not
embedded in another resource" (part of the definition of "Web page").

The scenarios I outlined can only occur where the same resource is
within the scope of two distinct conformance claims. Having considered
this furhter, I think it's reasonable to propose the following
solution.

Proposed Change:

"Not embeded in another resource" means "not embedded in another
resource covered by the same conformance claim", or wording to that
effect.

Note that if I place a resource (e.g., an image) on my Web site, make
a conformance claim applicable to the whole site, and reference the
image only in a link, without embedding it in any of my other
resources, then the image will count as an independent Web page, and
will be subject to all of the WCAG 2.0 conformance requirements at my
chosen conformance level, even if the link text provides a text
alternative. A resource that is linked to cannot be regarded as
embedded, otherwise many resources that should count as Web pages
would fail the definition simply in virtue of being linked to by other
resources within the scope of the conformance claim. I think these
consequences of the current definition, which are not affected by my
proposal above, are tolerable; but it does appear that if a content
author has a collection of images and refers to them only in links, it
will be necessary for example to wrap each image in an HTML page to
prevent it from being an independent Web page under the definition.

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

Thank you for this exploration of this issue.  We have amended the
definition of Web page to say:

Web page
a non-embedded resource that is referenced by a URI plus any other
resources that are used in the rendering or intended to be rendered
together with it by a user agent

Note 1: Although any "other resources" would be rendered together with
the primary resource, they would not necessarily be rendered
simultaneously with each other.

Note 2: For the purposes of conformance with these guidelines, a
resource must be "non-embedded" within the scope of conformance to be
considered a Web page.

Example 1: A Web resource including all embedded images and media.

Example 2: A Web mail program built using Asynchronous JavaScript and
XML (AJAX). The program lives entirely at http://example.com/mail, but
includes an inbox, a contacts area and a calendar. Links or buttons
are provided that cause the the inbox, contacts, or calendar to
display, but do not change the URL of the page as a whole.

Example 3: A customizable portal site, where users can choose content
to display from a set of different content modules.

Example 4: When you enter "http://shopping.example.com/" in your
browser, you enter a movie-like interactive shopping environment where
you visually move about a store dragging products off of the shelves
around you into a visual shopping cart in front of you. Clicking on a
product causes it to be demonstrated with a specification sheet
floating alongside.

Received on Sunday, 4 November 2007 04:45:08 UTC