Your comments on WCAG 2.0 Last Call Draft of April 2006 (4 of 8)

Comment 45:

(Issue ID: LC-1068)

Spawned windows: As mentioned in a previous comment, the SC this maps
to outlaws change in context when a user does something, but doesn't
outlaw change in context without user initiation.

Proposed Change:

Create a new SC outlawing changes in context without user initiation
at Level 1 (I am happy to write this)

Response from Working Group:

The mapping has been removed from the WCAG document itself. The
working group will work in coordination with the EOWG WCAG 2.0
Materials Support Task Force in the creation of transition materials
and will consider these comments when the mapping is updated. We
intend to add SC 2.2.1 to the mapping for WCAG 1.0 Checkpoint 10.1.

The working group believes that the ability for user agents and AT to
suppress and/or notify users about pop-up windows, along with the four
success criterion (3.2.1, 3.2.2 3.2.5 and 2.2.1) address the concerns
about changes in context without user initiation.  Because there is
some functionality that cannot be supported without asynchronous
changes of context, SC 3.2.5 is a level AAA success criterion.

Comment 46:

(Issue ID: LC-1069)

Stylesheets: It could be argued that the sequence of content can
always be programmatically determined- otherwise it could not be
presented to the user in that particular sequence. Because 1.3.3 maps
to checkpoint 6.1, it is obvious that what is meant by the WCAG2 SC is
that if style sheets are used to manipulate the layout of text, then
the layout without style sheets must present a meaningful alternative.
However it can be argued that simply because a user agent (ie browser)
can interpret the style sheet to present information in a certain way,
that it is automatically programmatically determinable.

Proposed Change:

Clarify the SC 1.3.3

Response from Working Group:

Please note that the the definition of programmatically determined
specifically covers support by assistive technologies:
"determined by software from author-supplied data provided in a way
that different user agents, including assistive technologies, can
extract and present this information to users in different

CSS can be used to position items visually on a page. While the
position is of course programatically determined, the reading order on
the basis of CSS positioning is not, because CSS lacks layout concepts
such as "previous" or "next" that would define, unambiguously, the
proper reading order of a graphical layout. In theory, advanced
heuristics might be able to extrapolate this information, but such
approaches are not supported by current tools so this is not a
sufficient technique at this time. Therefore, this success criterion
does have relevance and it is recommended to follow the sufficient
techniques provided.

Comment 47:

(Issue ID: LC-1070)

Baseline CSS: This mapping essentially says that if CSS is in the
baseline then information can be put into the style sheet and not in
the HTML. This appears to allow formatting (ie headings) via CSS and
not HTML, important images included in CSS and not HTML, etc. How is
someone who uses a screen reader going to interpret this? How are they
going to be able to access the information they require?

Proposed Change:

Clarify baseline requirements

Response from Working Group:

If CSS is an accessibility-supported Web technology, then the author
can rely on it to satisfy success criterion. However, the success
criterion must still be satisfied. So, for instance, if non-text
content that conveys information is included via CSS, SC 1.1.1
requires that a text alternative also present equivalent information.
This information must be programmatically determined, that is, exposed
to assistive technologies.

So even if most of the features or functionality of a Web technology
are accessibility supported, it may not be possible to use certain
functionality in the technology and still conform to WCAG.

We have completely rewritten the Conformance section, and this should
now be clearer.

Comment 48:

(Issue ID: LC-1071)

Properly positioned labels: 10.2 no longer maps to any particular SC.
Although this checkpoint was included in WCAG1 to assist people who
use screen readers, prior to the uptake of explicit labelling, this is
still a very important SC for people who use magnifiers and people
with cognitive disabilities.

Proposed Change:

Create a new SC the equivalent of 10.2 (I am happy to write this)

Response from Working Group:

Assistive technology has advanced since the WCAG 1.0 guidelines were
released. As long as the label is explicitly associated with a field,
assistive technologies can present the information to the user in an
understandable manner. However, since visual positioning can be
important, especially for pages translated into other languages, we
have added an advisory technique to Success Criterion 1.3.1 and
Guideline 3.2 titled "Positioning labels to maximize predictability of

Note: The mapping has been removed from the WCAG document itself. The
working group will work in coordination with the EOWG WCAG 2.0
Materials Support Task Force in the creation of transition materials
and will consider these comments when the mapping is updated.

Comment 49:

(Issue ID: LC-1072)

Advisory techniques: There should not be any advisory techniques
unless they are linked to a particular SC. Having advisory techniques
linked to a GL only, means that the level (A, AA or AAA) is not

Proposed Change:

Move all GL advisory techniques to specific SC

Response from Working Group:

Because WCAG 2.0 success criteria are written as testable statements,
it  is not always possible to associate techniques that are difficult
to test or subjective in nature with success criterion. However, the
working group feels that it is important to make these technqiues
available for authors who are interested in improving the
accessibility of their content beyond the minimum conformance
requirements. Note that regardless of association with a success
criterion or guideline, whether an author chooses to implement
advisory technqiues does not impact the level of conformance claimed.

Comment 50:

(Issue ID: LC-1073)

Add failure: Add a failure where a long description is not descriptive enough

Proposed Change:

I am happy to create this failure

Response from Working Group:

Thank you for the suggestion. We have created a Failure Technique for
Success Criterion 1.1.1 titled, "Failure of 1.1.1 due to providing
long description for non-text content that does not serve the same
purpose or does not present the same information."

Comment 51:

(Issue ID: LC-1074)

Example 3: Why isn't a long description required?

Proposed Change:

Add to example that a long description is required which gives the
same information as the image

Response from Working Group:

Since the animation is fully explained in text a longdesc would be
redundant and end up having the user who is blind listening to the
description twice. So the alternate text provides a short description
and mentions that the animation is described in the text that follows

Comment 52:

(Issue ID: LC-1075)

Example 6: Add another alt text example "Shaking a world leader's hand
can subtly affect the distribution of power in the relationship" and
"Shaking hands is a purely Western artifice"

Response from Working Group:

The Working Group feels that your first proposed example reveals an
opinion and is thus not appropriate alternative text for the situation
described in the photograph.  While the second alternative may be
true, it does not sufficiently describe the image.  We have not
updated the example with these additional alternatives. Instead, we
are including the following example:

On one page a checkmark is used to indicate that an item should be
ordered and and on another page it is used to indicate that a step has
been completed.  The same alt text "checked" could be used but since
they serve different purposes, different text alternative may make it
easier to understand.

Comment 53:

(Issue ID: LC-1077)

Transcripts: Why isn't this at Level 1?  Shouldn't the equivalent
information be provided at Level 1?

Proposed Change:

Move to Level 1

Response from Working Group:

Success criteria 1.2.2, 1.2.3 and 1.2.7 build upon one another. At
Level A, SC 1.2.2 can be satisfied either by providing a full text
alternative for multimedia or by providing audio description of the
video. At level A, multimedia will either have a full text alternative
or an audio description.

At Level AA, SC 1.2.3 requires an audio description. So multimedia
that satisfies level AA either has only an audio description, or both
an audio description and a full text alternative.

At Level AAA, SC 1.2.7 requires a full text alternative, so at level
AAA content will have both  an audio description and a full text

Success criterion 1.2.7 is not required at Level A because audio
descriptions are usually more effective than transcripts. This is due
to the fact that they contain much additional rich audio information
from the sounds track and because they allow individuals who are blind
the option of viewing the material with other people. Full text
descriptions, however, are an option for meeting this guideline at
Level A.

Comment 54:

(Issue ID: LC-1078)

SCOPE: One of the HTML techniques is to usee the scope attribute to
associate header cells and data cells in tables. Research has shown
that SCOPE is not supported by any known assistive technology and
therefore should not be advocated.

Proposed Change:

Remove the SCOPE HTML technique, OR indicate that it is not supported
yet, and TH & TD are preferable

Response from Working Group:

We have added a User Agent note on H63 that warns users about the poor
support in earlier versions of sceen readers. Current screen readers
have come a long way in supporting SCOPE but there are still some
minor problems. At the current time, we recommend the use of the
element wherever possible. However, there are some circumstances where
SCOPE is desirable. We have added a similar note to the table
techniques (H51 and H43) recommending the TH element over the Scope
attribute and suggesting the use of Stylesheets to adjust the look of
the TH element.

Comment 55:

(Issue ID: LC-1079)

Example 1 - "A form that uses colour and an asterisků": Research has
shown that screen readers differ in their approach to asterisks - some
do not read them out at all.

Proposed Change:

Remove this example, and provide additional examples, such as using
the word "required" instead of an asterisk (I am happy to write these)

Response from Working Group:

The Working Group tested three screen readers for support of the
asterisk character. Two of three spoke the asterisk character using
the default settings.  In one screen reader the default settings had
to be modified in order for the asterisk character to be spoken.  The
group feels that this level of support for the asterisk character is
sufficient to include the example.  However, we understand that screen
readers in languages other than English my have difficulty speaking
single characters so we have also included the example from How to
Meet 1.3.2 , A form that uses color and text to indicate required
fields, in the How to Meet document for 1.3.1.

Comment 56:

(Issue ID: LC-1080)

Add failure: Add a failure where the default underline is removed from
linked text - therefore links are only differentiated from normal text
through colour alone

Proposed Change:

I am happy to create this failure

Response from Working Group:

The committee agrees that underlined links are important when they are
part of a sentence or paragraph or other area where they could be
mistaken as non-linked text.

However, there may be good reasons to remove underlining when the link
is part of a navigation bar, site map, table of contents or other
navigation structure that contains many links together. In cases where
it is clear that all text is linked, the removal of the underlines
would make less clutter and therefore could help some people with
cognitive disabilities. Also there are instances where low vision or
users with cognitive disabilities find that underlines inhibit
accessibility and some users have asked us to allow webmasters to use
some other visual non-colour clue apart from underlines for links.
Therefore, we have provided the following failure:

F73: Failure of SC 1.4.1 due to creating links that are not visually
evident without color vision

Comment 57:

(Issue ID: LC-1081)

Example 2: As previously discussed, people who use screen readers
(people with vision impairments and people with dyslexia) expect that
the order of the site with CSS on matches the order of the site with
CSS off

Proposed Change:

Change this example so that the order of the content is the same with
CSS on or off

Response from Working Group:

Success criteria 1.3.2 (formerly 1.3.3) does not require that the
reading order be the same with CSS off as with it on. It only requires
that if the order can change the meaning, the correct order can be
determined. Example 2 is therefore an appropriate illustration of
conforming to this success criterion.

Comment 58:

(Issue ID: LC-1082)

Needs examples: This SC needs examples in order to fully understand
the implications

Proposed Change:

I am happy to create some examples (eg. See the use of dots - and
equivalents - at:

Response from Working Group:

We have added two examples to the How to Meet document of 1.3.3
(formerly 1.3.5).

Comment 59:

(Issue ID: LC-1083)

Move to Level 1: From what I understand, this is the equivalent of
making sure information is not provided via colour alone, so why is it
at Level 2?

Proposed Change:

Move 1.3.5 to Level 1

Response from Working Group:

Because assistive technology may not be able to preserve shape, size,
visual location, or orientation of components when it transforms
content to an alternate presentation, this success criterion has been
moved to level A.

Received on Thursday, 17 May 2007 23:47:56 UTC