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

Dear Joe Clark ,

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/Pine.LNX.4.60.0605231708530.14640@aristotle.multipattern.com
(Issue ID: LC-842)

See article TO HELL WITH WCAG 2.0 at:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0118.html

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

Given the format of the article it is difficult to know exactly what
issues the comment would like the Working Group to address. We have
attempted to extract issues from the article that apply to the
Guidelines document.

[THWW] 1. Exactly what a "page" is, let alone a "site," will be a
matter of dispute.

Response: We have replaced the term "Web unit" with "Web page".

[THWW] 2. A future website that complies with WCAG 2 won't need valid
HTML--at all, ever. (More on that later.) You will, however, have to
check the DOM outputs of your site in multiple browsers and prove
they're identical.

Response: Validity is still not required (although it is the #1
recommended sufficient technique for meeting SC 4.1.1). Also, SC 4.1.1
has been changed to "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."
There are no longer techniques based on DOM outputs.

[THWW] 3. You can still use tables for layout. (And not just a
table--tables for layout, plural.)

Yes, this is correct. Although WCAG 2, like HTML 4.01, 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.

[THWW] 4. Your page, or any part of it, may blink for up to three
seconds. Parts of it may not, however, "flash."

Reponse: This is correct. Short blinking to get attention is allowed
as long as it doesn't last long.   Flashing is also allowed if it is
very small or not very intense.  Flashing that is known to cause
seizures however is not allowed.  The glossary defines the difference
between blink and flash:

 Blink: turn on and off between 0.5 and 3 times per second
    Note: The slower blink is in contrast with flashing, which refers
to rapid changes in brightness which can cause seizures. See general
flash threshold and red flash threshold.


[THWW] 5. You'll be able to define entire technologies as a list of
the specific Baseline Technologies meaning anyone without that
technology has little, if any, recourse to complain that your site is
inaccessible to them.

Response: The term "baseline" has been replaced by "web technologies
that are accessibility supported". We have clarified what needs to be
true about user agent support (including AT) for a technology to be
considered accessibility-supported. Of course users may challenge the
assessment of whether a technology is accessibility-supported.

[THWW] 6. You'll be able to define entire directories of your site as
off-limits to accessibility (including, in WCAG 2's own example, all
your freestanding videos).

We have changed the wording to make this clearer.  As with all W3C
content technologies, you state what conforms.   We are leaving to
customers, organizations or policy makers to set policy about what a
site is and how much of it must conform.

[THWW] 7. If you wish to claim WCAG 2 compliance, you must publish a
checklist of declarations more reminiscent of a forced confession than
any of the accessibility policies typically found today.

Response: The required information for a claim doesn't seem excessive
or onerous:
1. The date of the claim
2. The guidelines title/version
3. The guidelines URI
4. The conformance level you are claiming
5. A list of the specific technologies you have relied upon (and are
assuming are accessible) in making your claim
6. What it is that you are claiming conforms (which URIs).

The rest of the points in a conformance claim are all optional.

[THWW] 8. Not that anybody ever made them accessible, but if you post
videos online, you no longer have to provide audio descriptions for
the blind at the lowest "conformance" level. And only prerecorded
videos require captions at that level.

Response: this is correct.

[THWW] 9. Your podcasts may have to be remixed so that dialogue is 20
decibels louder than lengthy background noise.  (You don't have to
caption or transcribe them, since they aren't "multimedia" anymore.
However, slideshows are now officially deemed to be "video," which
will come as a surprise to Flickr users.)

Response: SC 1.4.5 (the background sound requirement) is a Level AAA
requirement. If you want to make your podcasts very accessible you
would not have loud background sounds behind your speech.  If the
podcast is just speech with no other significant sounds, then captions
are not required but a transcript is (under 1.1.1 since it is non-text
content).  Slideshows that have audio would be multimedia.  A
slideshow without sound or interaction would not be multimedia.

[THWW] 10. You can put a few hundred navigation links on a single page
and do nothing more, but if you have two pages together that have
three navigation links each, you must provide a way to skip
navigation.

Response: this is correct.

[THWW] 11. You can't use offscreen positioning to add labels (e.g., to
forms) that only some people, like users of assistive technology, can
perceive. Everybody has to see them.

Response: We have made this clearer.  Labels are visible names on user
interface elements.  Names are sometimes visible and sometimes not,
but are accessible to AT.  Unless it is visually very obvious what a
control is for, names should be visible (labels) to make the forms
easier for people with cognitive disabilities.

[THWW] 12. CSS layouts, particularly those with absolutely-positioned
elements that are removed from the document flow, may simply be
prohibited at the highest level. In fact, source order must match
presentation order even at the lowest level.

Response: CSS layouts are not prohibited. Source order must match
presentation order only when it would change the meaning of the
content to present it in a different order.

[THWW] 13. Also at the highest level, you have to provide a way to
find all of the following:
          1. Definitions of idioms and "jargon"
          2. Expansion of acronyms
          3. Pronunciations of some words

Response: this is correct.

[THWW] 14. You also have to provide an alternate document if a reader
with a "lower secondary education level" couldn't understand your main
 document. (In fact, WCAG 2 repeatedly proposes maintaining separate
accessible and inaccessible pages. In some cases, you don't
necessarily have to improve your inaccessible pages as long as you
produce another page.)

Response: Providing an alternate document is one option for satisfying
SC 3.1.5. Providing supplemental information, such as illustrations or
multimedia, would be another way. Or writing your content in simpler
language in the first place.

     WCAG does not encourage separate accessible pages. WCAG 2 permits
alternate versions of Web pages because it may be helpful to have a
version of a page that is tailored for particular disabilities,
particularly for cognitive, language, and learning disabilities.
Alternate versions may also be used if an author is  providing
different versions for users with different user agent capabilities.
In order to claim conformance, the alternative pages must provide
equivalent information and an accessible mechanism for finding the
conforming version.

[THWW] What do the following terms really mean?

    authored unit
    authored component
    web unit
    parsed unambiguously
    programmatically determined

Response: "authored unit", "authored component", and "parse
unambiguously" have been removed from the guidelines. "Web unit" has
been replaced by "Web page".

     "Programmatically determined" remains.  It is a new term to
express the ability for user agents including AT to access
information. We have added examples to the definition to clarify.

[THWW] Testability section:

Response: The testability paragraph of the Conformance section now
reads "All WCAG 2.0 success criteria are written to be testable. While
some can be tested by computer programs, others require human testers
for part or all of the test. When people who understand how people
with different types of disabilities use the Web test the same content
using the same success criteria, the same results should be obtained
with a high level of confidence."

[THWW] Testability - "you'll notice that even something as
deceptively simple as that WCAG 1 guideline on clear and simple
writing isn't there."

Response: Testability is important so that an author can determine
whether WCAG has been satisfied.  The "Clear and simple" provision
from WCAG 1.0 is not in WCAG 2.0 as a Success Criterion because there
is no way for an author to tell whether language is "clear and
simple".  While there might be agreement that one version is simpler
than another, how does an author know that the simpler version doesn't
need to be simplified further?  When does it reach "clear and simple".
  When is a page on string theory or quantum mechanics 'clear and
simple'?
  This has been a tough area that the working group has wrestled with.
 The working group has tried to find ways to address this and related
issues both through testable requirements and through advisory
techniques.   WAI is also exploring a separate activity to see what
new techniques can be developed to address cognitive, language and
learning issues, as well as to find ways to provide focused advice on
just this area. This effort will look at how this is addressed
throughout different parts of WAI's work.

[THWW] Conformance levels

Response: The description of conformance levels in WCAG 2 has been
rewritten to clarify these issues:

The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.

  *In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.
  * The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.
  *Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content."


[THWW]: Standards

Response: The working group looked at the topic of standards
compliance 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.
   It should be noted that other W3C standards do not require
conformance to other standards.

[THWW]: Captioning and audio description for multimedia

Response: It is difficult to tell what WCAG 2 changes you would like
to see in this area, but it sounds as if you would like the
requirement for audio description and captioning of live multi-media
to be Level A requirements, while deploring the lack of support for
these WCAG1 requirements. The feasibility of providing captions and
audio description for all live content on the Web is a major question.
 We have received many comments on both sides of this issue.  After
reviewing them all and extensive discussions, the consensus of the
working group was to go with the current provisions as a best fit to
the issues.

Received on Thursday, 17 May 2007 23:37:21 UTC