W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > May 2007

Your comments on WCAG 2.0 Last Call Draft of April 2006

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:29:46 -0700
Message-ID: <824e742c0705171629h550e13dsa9dae0b7c006fe26@mail.gmail.com>
To: "David Keech" <david.keech@bsi-global.com>
Cc: public-comments-WCAG20@w3.org

Dear David Keech ,

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/20060622085028.A502866364@dolph.w3.org
(Issue ID: LC-878)

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

British Standards Institution (BSI) submission to the W3C on Web
Content Accessibility Guidelines 2.0 (WCAG 2.0).

BSI as the National Standards Body of the United Kingdom proposes to
raise the following issues in comments:

General Substantive Issues
1. Addressing Cognitive and Learning Disability [see LC-1408]

WCAG 2.0 claims to define and address the requirements for making Web
content accessible to those with learning difficulties, cognitive
limitations and others. We do not accept that claim.

Specifically, the success criteria requirements for making content
understandable largely ignore the needs of people with learning
difficulties and cognitive limitations. Please note that there are
guidelines published by other groups that will make content much more
accessible to these users. However, with the WCAG claim to address
learning difficulties and cognitive limitations, people will not know
that they need to look further.

We would like to see continued work in this field and a statement in
the WCAG 2.0 abstract and introduction modifying the claim that they
currently address accessibility for learning disabilities.
Specifically, we recommend removing learning difficulties and
cognitive limitations from the list of supported disabilities. A
sentence may be added later in the abstract that "these guidelines may
also provide some benefits for people with learning difficulties and
cognitive limitations". We would then like to see a statement of
intent such as: "the working group intends to build additional success
criteria to address accessibility for learning disabilities and
cognitive limitations."

2. Metadata [see LC-1409]

We recommend that WCAG 2.0 address the issue of locating good or
useable resources by requiring that every resource carry or refer to a
description of its accessibility characteristics. Without this the
best resources may not be found and a resource that is not universally
accessible may not be made available to
a user that could use it even if it is not useable to others.

This comment has also been made in
http://lists.w3.org/Archives/Public/public comments
wcag20/2006Jun/0091.html with which we agree.


Technical Comments

3.  [see LC-1410] WCAG defines a "web unit" as "one or more resources,
intended to be rendered together, and identified by a single Uniform
Resource Identifier ".  Resources can in addition consist of moving
images, or pages where part of the material is rendered through links
into Web Services (such as with AJAX technology). The example given in
the definition is static in nature - however in many situations in
today's web the end result is not static, or defined solely by a
single URI.

This appears to be clarified for a web unit in the section
"Conformance claims" - where it states that it "can also take the form
of a fully interactive and immersive environment"

However the situation becomes confused by later referring to
"Aggregated content" and giving, as an example of this, "a web unit
which is assembled from multiple sources that may or may not have
their own levels of conformance".  In a traditional web page,
containing graphics, (as is given as an example in the definition of a
"web unit"), this is conventionally exactly how images etc are
rendered using the  tag.

Statements such as "The conformance level for a Web unit that contains
authored units is equal to the lowest conformance level claimed for
the Web unit content and any of the authored units it contains 
including any claims pertaining to aggregated authored units"  are
extremely unclear, and indeed may be recursive following the unclear
distinction apparently made between "web units" and "aggregated
content".  A "web page" on the other hand is fairly well understood.
BSI recommend(s) a closer look at an accurately defined and understood
syntax which is not open to misinterpretation and clearly conveys the
ideas being communicated.

4. Typo, section \"Choosing baseline technologies\": \"Both conditions
are necessary since some users many have browsers that support them
while others may not. " - should be ..may have browsers

5.  Typo, section "Use of technologies outside of the baseline" - "All
content and functionality are available .."  should be ".. is
available"

6. In the section "Optional components of a conformance claim
consideration should be given to replacing the word "CANNOT" is not an
appropriate use of language. The language here needs clarifying
("shall not" ?).


7. [see LC-1411] In the section "Examples of conformance claims",
"jpeg" is specified as a requirement of one example (examples use
"Real Video" and "png" in a similar manner).  These are not testable
specifications in the same sense as XHTML 1.0 (Strict) - for example
progressive jpeg support was only added to many browsers long after
the basic sub-baseline jpeg (actually correctly JPEG) decoding was
implemented.  IS 10918-1 | T.81 (which presumably is what is intended
by JPEG) defines a 'shopping list' of image compression techniques,
including a baseline.  Actual JPEG implementations excludes many items
in the list, and add other items (typically JFIF/EXIF file support),
and are, almost without exception, sub-baseline.  A claim that an item
"relies upon" jpeg (sic) is fairly meaningless, and is dependent on
many things other than a correct interpretation of parts of IS 10918-1
(for example bit resolution and colour rendering of the display)

8  [see LC-1412] A number of the test criteria and  suggested
'solutions' are far from clear.  For example, Guideline 1.2 at level 3
success criteria suggests the use of sign language interpretation for
multimedia.  Following the references in the specification lead to the
"Understanding WCAG 2.0" document suggests including a sign language
interpreter in the corner of the video stream.  There are many sign
languages - for example English and US sign languages are different
and believed to be mutually unintelligible.  No suggestion is made as
to how to resolve this for (for example) an English language
documentary.  Clearly in this instance one possible solutions would be
to use overlay replaceable video technology (as offered for example in
MPEG-4 technology) rather than conventional digitised video as offered
by MPEG1 or MPEG2 technology.

9 [see LC-1413] Comments on Appendix A - Glossary (Normative). This
section should be re-written (preferably by a standards editor).
Almost every definition is inaccurate, inappropriate or unnecessary.
Several are simply incorrect. Starting just with those beginning with
A...

Definition of acronym is incorrect (relates to definition of
abbreviation and initialism). An acronym is \"A word formed from the
initial letters or parts of other words\" (SOED).  An initialism is a
subset of this, being formed from initials.  Missing out the words
'parts of other words' is both incorrect and makes initialism and
acronym identical.

Definition of "activity where timing is essential".  'Timing' should
be defined for clarification (or better described in the definition).

Definition of "analog, time-dependent input" - This is 'analog,
time-dependent movement', presumably as opposed to "digital, time
dependent movement".  Whilst not being very clear, adding a definition
which constrains this to a very specific meaning in the context of a
pointing device may not be useful.  The wording should stand on its
own as English text, and is not proper to a definition section.

Definition of ASCII art.  It is assumed that an image rendered from
many small images would classify as ASCII art (examples exist).  The
spatial arrangement is therefore of glyphs (or similar small sized
graphical objects), not characters - their rendition is what provides
the pseudo-photographic output.

Definition of "authored unit" (and implicitly "authored component").
See comments above about confusion between authored unit, component
and web unit)

Other errors include: Re-definition of text (SOED: the wording of
something written or printed). Unicode is defined by the Unicode
Consortium (www.unicode.org) and no longer aligns with ISOIEC 10646-1
(or 106464, whatever that is supposed to be!)

Some definitions (eg Luminosity contrast ratio) are in the vein of
defining pi as 22/7 - input from the relevant standards body (eg CIE)
could have avoided these basic errors.  In several places, values are
referred to as RGB without any reference to colour spaces.  Many
definition would be much improved by using the same word definitions
as are used in other Standards, where similar terms are correctly
defined, and then simply referred to the appropriate Standard in the
definition (or worst case by repeating verbatim the wording used in
the Standard)

10. For any reader who needs to get to grips with WCAG 2.0, the volume
of associated written material is daunting to say the least, with the
three core WCAG 2 documents coming in at 160,000 words. The fact that
the 'understanding WCAG 2' document is more than double the length of
the document it explains is worrying. Ultimately, (and ironically) the
new web standard for accessibility is initially made inaccessible by
the density and volume of associated material.

11. It is not desirable to still be able to use tables for layout, as
in http://www.w3.org/TR/WCAG20-TECHS/#N11001

12. [see LC-1414] The role of blinking and flashing content is confused -
http://www.w3.org/TR/WCAG20/complete.html#time-limits-blink  and
http://www.w3.org/TR/UNDERSTANDING-WCAG20/#seizure-does-not-violate-terms

Proposed Change:

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

Where they were tracked individually in our database, the issues
number assigned to individual items are included in square brackets.

#1 Addressing Cognitive and Learning Disability [LC-1408]
We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.

We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques, and we have proposed 3
new success criteria in this area.
___________________________________________________________
#2 Metadata. [LC-1409]
While the working group agrees that metadata describing the
accessibility of a resource is beneficial for a number of reasons,
WCAG 2.0 does not require this information. There are many reasons we
do not, including the fact that conformance claims are not always
required, may not be available publicly and in some cases can not be
made due to legal constraints.

Although we are not changing WCAG conformance, we recognize the value
of what you request. Therefore, the WG hopes to provide WCAG 2.0
supplementary materials containing techniques for generating
conformance claims as well as guidance about the various strategies
for providing accessibility metadata that are available today.

This approach allows us to revise recommendations about accessibility
metadata over time to adapt to changing technologies and
recommendations related to generating and providing this information.
___________________________________________________________
#3. [LC 1410]
We have replaced the term "Web unit" with "Web page" and have modified
the conformance section to clarify these concerns.
_____________________________________________________________
#4.
This was removed in a rewrite of the conformance section.
___________________________________________________________
#5
Edit accepted
___________________________________________________________
#6
The Conformance section has been completely rewritten. It no longer
uses the word "cannot".
___________________________________________________________
#7 [LC-1411]
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 .

The reason that JPEG is specified in this example is that non-text
formats such as JPEG or PNG may be "relied upon" technologies for
conformance claims which include success criterion 3.1.5, which
encourages authors to provide additional content that illustrates or
clarifies the primary content.

While we agree that there is ambiguity in simply listing "JPEG" when
it comes to the implementation details you outline in your comment, we
believe that this concern would be covered by the definition of
accessibility-supported technologies, which includes support by a wide
range of user agents and assistive technologies.
___________________________________________________________
#8 [LC-1412]
There is already a note on the technique which addresses the first
part of your issue. It reads:
"Note: Since sign language is not usually a signed version of the
printed language, the author has to decide which sign language to
include. Usually the sign language of the primary audience would be
used. If intended for multiple audiences, multiple sign languages may
be used. Refer to advisory techniques for multiple sign languages."

With regard to the second aspect of your comment - Yes, it is also an
approach and is mentioned in G81 ("displayed in a different viewport
or overlaid on the image by the player"). We also have a SMIL
technique for doing this. If you would like to write up another
technique on that we would be happy to review for inclusion.
Techniques can be submitted to
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/
___________________________________________________________
#9 [LC-1413]
We appreciate responses of people in the standards field and have
received much input which has helped us arrive at the definitions we
currently have. We have taken into consideration your comments and
have made the following changes:

The definition of acronym now reads "abbreviated form made from the
initial letters or parts of other words (in a name or phrase) which
may be pronounced as a word
Example: NOAA is an acronym made from the initial letters of the
National Oceanic and Atmospheric Administration in the United States."

Timing: This is the ordinary dictionary definition of 'timing'. By
policy we don't define words that are used in their ordinary fashion.

"analog, time dependent": We have removed this term from the success
criterion and from the glossary.

ASCII ART: We have changed "characters" to "characters or glyphs"

Authored Unit: We have eliminated the definition of authored unit for
(among others) the reasons you have cited.

Text/Unicode: We have removed references to Unicode.

Luminosity contrast Ratio: This has been revised to include references
to the standards on which it was based as well as tie to color space
specifications.
___________________________________________________________

#10
The guidelines are only 12 pages long.  We have removed some very long
appendices to make the document shorter.  The Understanding WCAG 2.0
should be much longer than WCAG.  It is intended to act as a reference
text with much supplemental material.  A sort of reference text book.
 For a nice short version of the guidelines we recommend you check out
the Quick Reference at www.w3.org/WAI/WCAG20/quickref/.  It has all
the WCAG 2.0 requirements along with sufficient techniques to meet
them and it is approximately 20 pages long. It can be made shorter if
you are only interested in some types of techniques.
___________________________________________________________
#11
Regarding use of layout tables, if done properly, they do not pose
accessibility issues. WCAG tries to characterize the difference
between accessible use and common uses that are inaccessible.

While WCAG2 does not prohibit layout tables, it recommends the use of
CSS: "Although WCAG 2 does not prohibit the use of layout tables,
CSS-based layouts are recommended in order to retain the defined
semantic meaning of the HTML table elements and to conform to the
coding practice of separating presentation from content."
___________________________________________________________
#12 [LC 1414]
We have made the following changes to clarify the differences between
blink and flash:

The following note was added to the definition of "blink":
Note: The slower blink is in contrast with flashing, which refers to
rapid changes in brightness which can cause seizures. See general
flash and red flash thresholds.

The following paragraph was added to the intent section of How to Meet
Success Criterion 2.3.1:

"Flashing can be caused by the display, the computer rendering the
image or by the content being rendered. The author has no control of
the first two. They can be addressed by the design and speed of the
display and computer. The intent of this criterion is to ensure that
flicker that violates the flash thresholds is not caused by the
content itself. For example, the content could contain a video clip or
animated image of a series of strobe flashes or close-ups of rapid
fire explosions."
Received on Thursday, 17 May 2007 23:30:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:07 UTC