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 21:16:12 -0700
Message-ID: <824e742c0711032116k68d3082eg27bfdad452a03c6d@mail.gmail.com>
To: "Cecil Ward" <cecil@cecilward.com>
Cc: public-comments-WCAG20@w3.org

Dear Cecil Ward,

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

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.


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: Exceptions for single words and other classes of words
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0236.html
(Issue ID: 2069)
Original Comment:

Why does SC 3.1.2 not apply to single words? It should do so. The
document already gives an appropriate set of exceptions, such as
dictionary-listed foreign words, so there is no reason to feel a need
for 'blanket' exceptions without justification. Having a speech
synthesizer fail on a single word is a problem too.

Why are proper names and technical terms exempted too? (Or is this
just badly worded?)

Proposed Change:

Remove the exception for all single words. Consider emphasizing the
existing exception for exception that established foreign loans and
other foreign words likely to be listed. (Possibly further research is
required into the coverage of current speech synthesizers'

Clarify/re-word the sentence:  "It also does not apply to proper
names, to technical terms or to phrases that have become part of the
language of the context in which they are used."

to read "It also does not apply to words or phrases that have become
part of the language of the context in which they are used."

There's nothing special about foreign proper names or technical terms
that makes them any more inherently "speakable" by speech synthesizers
than other words and phrases.

Response from Working Group:

We have removed the blanket exception for single words, but retained
the exception for proper names and technical terms.

Proper names generally are not considered part of the vocabulary of a
language; you cannot look them up in a dictionary. However, it should
not be necessary to markup Mr. Schneider's name as German just because
his great-great-grandfather was from Germany. If the pronunciation of
the name is an issue, it is covered by SC 3.1.6.

Technical terms have similar issues, since they are often shared
directly between languages.

Comment 2: "easier" (than what?)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0237.html
(Issue ID: 2070)
Original Comment:

In the text for Guideline 1.4, "Make it easier for people with
disabilities to see and hear content including separating foreground
from background", the word "easier" ought to be changed to "easy"
(say). ("Easier" than what?)

Proposed Change:
change the word "easier" to simply "easy" (say).

Response from Working Group:

"Easy" is an absolute term and hard to define. We're using the phrase
"make it easier" because we're striving for plain language alternative
to the concept of "facilitate."

Comment 3: SC 3.1.2: Suggested additional qualification
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0238.html
(Issue ID: 2071)
Original Comment:

I suggest that the text of SC 3.1.2 might usefully be extended. It is
necessary for authors to ensure that web content be marked up in such
a way as to avoid inappropriate choices of language-change boundaries,
to make sure that each language-marked part forms an appropriate unit
that can be comprehensibly spoken by a speech synthesizer.

This is issue is less likely to arise with some languages, such as
English which is an isolating language, but in other language types
its likelihood of occurrence and its impact in terms of speakability
and comprehensibility may be greater.

In fact this "don't break up meaningful units" philosophy ties in with
guideline 1.3, especially in view of its phrasing "can be presented
... spoken aload ... without losing information or structure".

Proposed Change:
Add something like "... and ensure that web content be marked up in
such a way as to avoid inappropriate choices of language-change
boundaries, to make sure that each language-marked part forms an
appropriate unit that can be comprehensibly spoken by a speech

Response from Working Group:

This would not be supported by existing technology, and the Working
Group does not believe many authors would have the multilingual
expertise to be able to determine if speech synthesizers are
pronouncing words correctly.

Comment 4: 2.4.8 Wording not explicit enough, and too similar to 2.4.4
Source: (@@ archive reference missing)
Original Comment:

SC 2.4.4 versus 2.4.8 - The wording of 2.4.8 is confusingly similar to
2.4.4 so that it is quite unclear what if any difference there is
between the two.

The term \"link text\" is undefined. For example, in (X)HTML, does
this include the content of any title attribute as well as the text
node that is the child of the <a> element.

Proposed Change:
Changes to 2.4.4 wording as well as to 2.4.8 to clarify by
highlighting the distinction.

[Assuming that I have managed to correctly guess what was intended,]
then the problem can be resolved by adding somthing along the lines of
 the phrase "if necessary, with context taken into account" (or
similar) to 2.4.4


"when read out of context" to 2.4.8. Anyway, the word "context" should
appear in both, clearly contrasted.

Response from Working Group:

In order to clarify the difference between SC 2.4.4 and 2.4.8, we have
changed SC 2.4.4 to read "2.4.4 Link Purpose (In Context): The purpose
of each link can be determined from the link text alone, or from the
link text together with its programmatically determined link context,
except where the purpose of the link would be ambiguous to users in

We have also changed SC 2.4.8 (now 2.4.9) to read:

"A mechanism is available to allow the purpose of each link to be
identified from link text alone."
Received on Sunday, 4 November 2007 04:16:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC