W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > March 2008

Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Mon, 10 Mar 2008 17:20:57 -0700
Message-ID: <824e742c0803101720l4fdc8dd6hb1219bd5f8fd57d1@mail.gmail.com>
To: "Roger Hudson" <rhudson@usability.com.au>
Cc: public-comments-WCAG20@w3.org

Dear Roger Hudson,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

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 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

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: doing a little more for people with cognitive limitations
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Dec/0051.html
(Issue ID: 2373)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Thanks for sending me the WG response to my response.

I am sorry but I just don't understand how you are suggesting 1.1.1 offers
any support for people with cognitive or learning difficulties. Guideline
1.1 and 1.1.1, from my reading of the latest last call draft, seem to
explicitly relate to the provision of text alternatives for non-text
content. What I was specifically concerned about were people who had a
problem reading or comprehending complex pieces of text, not people who need
text alternatives for non-text content for I feel they are adequately
catered for in WCAG 1 and 2.

Do I take from this comment, "we do not have any requirements on the quality
of the alt-text because that would create the same kind of testability
problem", that the Working Group is not going to be concerned about the
quality of the actual text alternative for non text content? If so, why
include the phrase "presents equivalent information"?

Regards

Roger

Roger Hudson
Web Usability
Ph: 02 9568 1535
Mb: 0405 320 014
Email: rhudson@usability.com.au
Web: www.usability.com.au
-----Original Message-----
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com]
Sent: Wednesday, 12 December 2007 10:44 AM
To: Roger Hudson

Cc: public-comments-wcag20@w3.org
Subject: Re: WCAG 2 response to WG response

Yes the alt-text is a good comparison.  And we do not have any
requirements on the quality of the alt-text because that would create
the same kind of testability problem.

The only failure is the use of the same placeholder term on all
graphics (since that is easy to reliably detect/test for).

Please note that there are many provisions at  Level A and Level AA
that provide access for people with cognitive disabilities such as
1.1.1 that allows content to be read aloud or translated into symbols
etc.   In fact a majority of the provisions relate to issues that have
been identified for one or another cognitive language or learning
disability.   We know that there are many other issues that we were
not able to address.  We have initiated an effort in conjunction with
the Cognitive RERC on developing an application note on access to Web
Pages by people with congnitive, language and learning disabilities
that is more general, qualitative, and not bound by testability so
that all guidance can be treated equally without levels or constraint
due to the nature of the advice.

Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

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

SC 1.1.1 ensures that all text is machine readable. That allows the
text to be translated into other forms to meet user needs. For people
with cognitive, language and learning disabilities it allows the page
to be read aloud, translated into a user's symbol system, or
translated into a simpler form. In fact we were talking to language
translation experts recently and they felt that this was a real
possibility using current and emerging language translation
technologies.

Regarding the quality of alt text, we do not require that it be of
high quality, but we do require that it be equivalent and we do
provide clear examples of things that are not equivalent.

----------------------------------------------------------
Comment 2: Cognitive Support
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0013.html
(Issue ID: 2389)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

The previous two drafts generated 1,500 comments which according to
the Working Group, "comprises a significant community contribution to
the guidelines". Much of the response by the Working Group to these
comments was in the form of additional clarifications and techniques
in two non-normative documents that do not have the status of WCAG
2.0.

WCAG 1.0 adopted a general position of offering guidance in the area
of accessibility; whereas during the development of WCAG 2.0, it
appears that a prime aim has been to prepare a document that is more
akin to a "standard". Perhaps, this is best illustrated by the Working
Group's determination that the value of a Success Criteria be
determined by its testability, and in particular machine testability.

Given this apparent move from offering guidance to providing a
(machine) testable standard, it would seem likely that the normative
components of WCAG 2.0 will be the main area of concern when
determining legal liability or responsibility for ensuring web
accessibility. It should be noted, that in regard to the definition of
"normative" the WCAG 2.0 Glossary states, "Content identified as
"informative" or "non-normative" is never required for conformance".

I am concerned that many issues relating directly to people with
cognitive, learning or language difficulties, which were raised in
response to the previous two drafts of WCAG 2.0, are still not
addressed in the core WCAG 2.0 document. In fact, I believe it could
be argued that from a legal perspective WCAG 2.0 offers less rather
than more protection or support than WCAG 1.0 for what is arguable the
largest community of disabled people in many countries.

Proposed Change:

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

We do not believe WCAG 2 offers less *protection* for people with
cognitive disabilities. While some provisions that might benefit some
users are not included, WCAG 2 does not prohibit conforming Web sites
from following such guidance, nor does it prohibit policies from
adding additional guidance (where testability is not a concern). The
additional resources provided are intended to support this.

While it is true that WCAG 2.0 has an emphasis on testable criterion,
it is not true that there is any bias toward machine testing except
for a couple provisions like 'flash' where things happen too quickly
to be evaluated well by humans. In fact almost all of the provisions
require humans in testing.

That said, it is true that the cognitive, language and learning areas
are some of the most difficult to identify testable techniques for
direct access. In WCAG 1.0, there were provisions like "Use the
clearest and simplest language appropriate for a site's content," but
in practice we found that the provision was largely ignored. The
attempt in WCAG 2.0 was to create provisions that could be tested and
that would be included when sites were tested.

We have tried to include all of the qualitative guidance that we have
received in the advisory techniques.  We have also re-written the
introduction to emphasize the importance of going beyond the testable
SC and implementing as many of the sufficient and advisory techniques
as possible.

In addition, the WCAG WG has initiated an effort to develop an
"application note" under the framework of WCAG 2.0 on access to Web
Pages by people with cognitive, language and learning disabilities.
The application note would include approaches that are more general,
qualitative, and not bound by testability, so that all guidance can be
treated equally without levels or constraint due to the nature of the
advice. This effort will include the Cognitive Rehabilitation
Engineering Research Center which focuses on cognitive disabilities,
and we welcome additional participation.

The WAI continues to be interested and committed to developing
guidance to address Web accessibility needs in the broad area of
cognitive disabilities, and will continue to explore this area through
our other WAI 2.0 guidelines, research discussions, and in potential
future guidelines development.

It is hopeful to note that assistive technologies for people with
cognitive disabilities, including free open source technologies, are
on the horizon.  A large number of the provisions in WCAG 2.0 are
designed to provide the information needed by these new and emerging
technologies.

The group feels that WCAG 2.0 has more enforceable provisions that
deal with cognitive language and learning disabilities than WCAG 1.0.
Still, the guidelines point out clearly that WCAG 2.0 is not enough
for these groups and that more work is needed and that Web authors
need to look beyond WCAG for all disabilities but particularly for
users with cognitive language and learning disabilities.

----------------------------------------------------------
Comment 3: accessibility of social networking site content
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0014.html
(Issue ID: 2390)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

During the last few years, there has been an explosion in the use of
social networking sites like Flickr, Youtube and Myspace and it is not
clear how WCAG relates to all this new content on the web. Much of the
content on these social networking sites does not comply with WCAG. It
is probably unreasonable to expect all the users of these sites to be
aware of what is required to make their contributions accessible and
unrealistic to assume that they will have the desire to do so.

When it comes to the accessibility of social networking sites, maybe
we should look more at the processes that allow people to put material
on the web, rather than the final content. That is, everyone should
have the opportunity to participate, for example the process should
allow a blind person as well as a person with cognitive limitations to
set up a blog or a myspace page or put photos up onto Flickr, and then
make this material available to as wider audience as they wish.

The applications (tools) should encourage the users of these sites to
include accessibility features. But if they don't, the application
should degrade gracefully so that the resulting content does not cause
problems for assistive technology users and wherever possible provides
some basic text alternatives derived from the titles or descriptions
provided by the person uploading the content.

Proposed Change:
The issue of the accessibility of user-generated content on social
networking sites should be directly addressed in WCAG. In particular,
there should be guidance about who is responsible for ensuring the
content of these sites is accessible and how this could be best
achieved.

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

WCAG describes the properties of a conforming web page, not the
process used to generate the web page. Because there is a mix of
authors on social networking web pages, with the users becoming
authors of parts of their own pages, they are examples of Web pages
which may only be able to make a statement of partial conformance.
(http://www.w3.org/WAI/GL/WCAG20/#conformance-partial) The Web site
authors make the standard portions of the Web pages conform to WCAG 2
but they cannot make the full page conform without monitoring it and
fixing any non-conforming content. Those pages would have to be
excluded from a claim of conformance but could state that they would
conform if all contributed content is excluded.

Since such sites are often authoring tools, they should be encouraged
to meet the Authoring Tool Accessibility Guidelines, as well.

----------------------------------------------------------
Comment 4: meaningful and logical sequence
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0015.html
(Issue ID: 2391)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

The actual wording of this Criterion appears to relate only to the
need for a "correct reading sequence" to be programmatically
determined. No definition is provided for what is meant by "correct
reading sequence" and the Understanding SC 1.3.2 document appears to
be primarily concerned with ensuring assistive technologies do not
distort the presentation of material in such a way as to confuse the
users of these technologies.

I feel that it is also important for material to be presented in a
logical and clear way, particularly for people with cognitive and
learning disabilities. Of course, I recognise it is not possible to
determine if something is "logical" with a machine; however I believe
it is very possible for human testers to reliably determine when the
sequence of content or information is not meaningful or logical.

SC 1.3.2 should be rewritten so that it is also able to provide some
assistance to people with cognitive limitation, see following example;

Proposed Change:
1.3.2 Meaningful Sequence: When the sequence in which content is
presented affects its meaning, the reading order of the material is
logical and a correct reading sequence can be programmatically
determined. (Level A)

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

A correct reading order will be one in which the words of a sentence
are in order and the sentences of a paragraph are in order. That is,
the order of the words in the sequence cannot be changed without
affecting its meaning.

The working group has considered the use of "logical" in various
success criteria in the past, and has come to the conclusion that it
is not testable. In this case, the current explanation of correct
reading order captures the property that human testers would find
agreement about.

We recognize that there are additional requirements related to how
information is organized that affects people with some cognitive and
learning disabilities. However, we have not been able to develop
success criterion for determining when the content has been organized
in a way that addresses those requirements.

----------------------------------------------------------
Comment 5: meaning of accessibility supported unclear
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0016.html
(Issue ID: 2392)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

The whole issue of "accessibility supported" evolved from the concept
of "Baseline" which was widely misunderstood and/or incomprehensible
by many people. Unfortunately I don't find "accessibility support"
much clearer. The definitions and descriptions of "accessibility
supported", which are provided in the WCAG 2.0 and "Understanding
Accessibility Supported" documents, and the implications for web
pages, I find difficult to understand.

Does the issue of "accessibility supported technologies" only come
into play if someone wishes to make a formal claim for conformance?
Or, does it also relate a more general determination of whether or not
a web page conforms to a particular Success Criterion? If so, who will
be responsible for determining the supported technologies?

When a regulator or court is asked to determine if a web site is
inaccessible, is it the expectation of the Working Group that the
guidelines for determining if a technology is accessibility supported
will be taken into consideration?

It seems to me that the information about "accessibility supported
technologies" in the WCAG document body and Glossary raises a number
of issues or questions including:

1. The document talks about a technology being able to support
accessibility but it does not appear to mention the implementation of
that technology. For example, Flash, AJAX, PDF that are well made can
be accessible, but poorly implemented are totally inaccessible. Is it
sufficient to use an "accessibility supported technology" or should
the use of that technology be accessible?

2. The Working Group and W3C don't see the need to specify "which or
how many assistive technologies must support a Web technology in order
for it to be classified as accessibility supported". Point 2 in the
Glossary says, "The web content technology must have
accessibility-supported user agents that are available to users". Does
this mean that a content technology can be considered accessible so
long as a version of user-agent that supports that content technology
is available in the market place regardless of the price of the
user-agent or how many people use it?

3. In my opinion, Point 2d in the Glossary is pretty worthless.
Charging someone with a disability more for a user agent (assistive
technology) than you would charge a non-disabled person is not really
the point and many countries have discrimination or trade laws that
would already cover this situation. Surely, the key issue is the
additional cost of accessing a web service that someone who is
dependant on an assistive technology needs to pay when compared to
someone who can access the same service without requiring an assistive
technology. Given that only one of the four conditions in Point 2
needs to be true, Point 2d appears to be the ultimate escape clause
under the guise of offering protection and needs to be rewritten.
Obviously, assistive technology manufacturers shouldn't be asked to
provide their products without charge. However, I believe it is
equally obvious that making available a 1 million dollar tool that is
priced the same for everyone, but is only essential for a person with
a disability who wants to access a specific service, is not an
equitable or fair solution.


I fully recognise that my interpretation of the meaning and intent of
"accessibility supported" maybe wrong, and if that is the case I
apologise for my mistake. But if I am wrong, then it is likely others
may experience problems understanding this.


Proposed Change:
The Working Group should consider re-writing the information relating
to "accessibility supported" with the aim of providing greater
clarity.

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

You raise a number of questions.  Lets look at them in turn.

RE your numbered questions:
1) It is necessary that conforming content both use techniques that
satisfy the success criteria, and that those techniques are
implemented using technologies  that are supported by user agents and
assistive technology.

One of the conformance requirements is that the success criteria must
be met using accessibility supported technologies.  However if one
uses accessibility supported technologies - but does not use them
properly then the SC would not be met (and of course conformance could
not be be claimed for levels that include that SC).  In the cases you
specified, the content would fail the SC so just using an
accessibility-supported technology but not using it properly would not
be adequate to claim conformance.  Note that HTML done poorly would
also fail the SC.



2)  The working group recognizes that the need for information on which
technologies are 'accessibility-supported' is important to use of the
guidelines.

Such data can only come from testing different versions of user
agents and assistive technology and recording whether the features of
the technology are supported. We expect that this information may
need to be compiled from multiple sources. WAI will be working with
others to establish an approach for collecting information on the
accessibility support of various technologies by different user
agents and assistive technologies.

WCAG 2.0 is still in development. We expect that during Candidate
Recommendation period we will have some initial information on
accessibility supported technologies, to demonstrate how this
approach will work once WCAG 2.0 becomes a W3C Recommendation.

The Candidate Recommendation process itself requires that there be
examples that demonstrate conformance. So there will certainly be some
information about accessibility supported technologies in order to get
out of the candidate recommendation stage for WCAG 2.0.

3) The first three items in part 2 (of the definition) that you cite
all involve the person with a disability using the same technology as
everyone else.  So the problem of a person with a disability paying
more would not arise.   The only reason that the language was required
in part (d) was that (d) allowed for a special version of a plug in.
For example, at one time the standard PDF plug in was not accessible.
Instead, a special version that was accessible was provided.
According to (d) that one had to be as easy to find and not cost any
more than the standard one.  Today, the standard PDF plug in is
accessible so it would fall under (b).   If you read (d) carefully it
says that the tools that the person with a disability must use cannot
cost more than the mainstream tools.  So other than people who must
use AT (and must pay for the AT) there cannot be additional 'services'
that are required that cost more than the services used by people
without disabilities.

Other questions you raised:

Question:  "Does the issue of "accessibility supported technologies"
only come into play if someone wishes to make a formal claim for
conformance? Or, does it also relate a more general determination of
whether or not a web page conforms to a particular Success Criterion?
"
Answer: It relates to conformance, regardless of whether a claim is
made or not.

Question:  "If so, who will be responsible for determining the
supported technologies?"
Answer:  The author is responsible.  They may rely on lists provided
to them by others (the field, their company, a customer, etc.)

Question: "When a regulator or court is asked to determine if a web
site is inaccessible, is it the expectation of the Working Group that
the guidelines for determining if a technology is accessibility
supported will be taken into consideration?"
Answer:  Yes.  If the regulation or court is using WCAG 2.0 as a
reference they would usually use (and should use) all the normative
aspects of WCAG 2.0.  What regulators or courts actually do, though,
is up to them.


----------------------------------------------------------
Comment 6: Media exemption to 1.1.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0017.html
(Issue ID: 2393)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

I don't fully understand the intention of the "media" exemption to the
requirement to provide a text alternative for all non-text content
under SC 1.1.1. I assume it is an attempt to accommodate the
increasing presentation of audio and video material on the web by
media not traditionally associated with the web; and, the need to
balance the accessibility implications of this use with a desire to
have guidelines that don't impose undue hardship on web proprietors or
stifle the development of the web.

The terminology used for the Media related exemption is potentially
ambiguous in the context of the broadcast industry. In particular, it
appears to address just two distinctly different programming formats,
"live" and "prerecorded", without providing adequate definitions for
either.

The WCAG 2.0 Glossary defines the term "live audio-only" as "a
time-based live presentation that contains only audio" and a very
similar definition is provided for "live video-only". While these
definitions might be adequate for a sports broadcast or the coverage
of an unfolding news event, they do no appear to be sufficient for
many of the situations faced by the broadcast media today.

The current definitions of live audio-only and live video-only need to
be expanded in order to meet the real-world needs of the media. The
phrase 'time-based' is not very meaningful since within the broadcast
industry all material could be said to be time-based.

The proposed Media exemption does not recognise that sometimes a media
broadcast (program) might be an amalgam of live and prerecorded
material. For example, daily live radio programs often contain
prerecorded segments: In some cases differences in time-zones or the
schedule of the interviewee require an interview that is presented
live to be prerecorded; or a live program may incorporate prerecorded
documentary-style feature segments. With regard to television, it is
not uncommon to have programs that are presented as live, but which in
fact consist entirely of prerecorded segments with the only live
component being the studio presenter who tops and tails them, and in
some cases even this is prerecorded.

Also, the broadcast of live-to-air (real-time) programs that contain
absolutely no prerecorded material is becoming increasingly rare; even
sports broadcasts often now contain prerecorded comments from the
players. It should be noted, the Guidelines indicate use of
"prerecorded" audio and video "files" is covered by SC1.1.1, but no
definitions are provided for the words "prerecorded" and "files". Does
a prerecorded interview with a player that is stored as an audio file
require a text alternative within the context of the WCAG 2.0? Or,
should it be treated as being part of a live audio or video
presentation and so require only a descriptive label?

The increasing convergence of media is resulting in more and more
radio and television broadcast material now being presented over the
web in a variety of ways. For example, ABC Radio National in Australia
produces live and prerecorded programs and simultaneously "streams"
all them over the internet at the time of broadcast. 95% of these
programs are also available as "streamed media on demand", which means
they can be listened to (but not downloaded) at a different time. In
addition, over 50 of the daily or weekly programs are available for
download as MP3 or Podcast files. These are primarily word based
(non-music) information style programs. I understand the national
broadcasters in Canada and the UK do something very similar.

The presentation of steamed media on demand and podcasts on websites
may further complicate the distinction between live and prerecorded
content. This material, by its very nature, is not live in the sense
that it is a recording of something that has happened at sometime in
the past. In some cases however, it might be a recording of a
live-to-air program and as such may be considered an alternative
presentation of the initial program and so exempt from the need to
provide a text alternative; this assumes the initial program is a
live-only program within the meaning SC1.1.1.

>From a practical point of view, it might be useful to consider making
a distinction between 'scripted' and 'non-scripted' content since any
requirement to provide a text alternative for a scripted program is
likely to be less onerous. However, this should not mean that
'non-scripted' material with historical value (e.g. an interview with
someone concerning a significant world event) is exempt from the
requirement to provide a text alternative when it is being presented
on the web for posterity.

Is the intention of the Media exemption to SC 1.1.1, and the
associated definition, to exempt only live-to-air material from the
need to provide a text alternative? And consequently, require all
prerecorded material that is contained in a television or radio
program to have a text alternative when it is presented on the web. If
so, the considerable difficulties most broadcasters will experience in
meeting such a demand is likely to lead to it being generally ignored.
And, a general refusal by the broadcast industry to conform to a Level
A Success Criterion could undermine the status of WCAG.

Proposed Change:
The Glossary should contain definitions for the terms "live" and
"prerecorded" that relate to the current status of the broadcast
industry and are likely to be meaningful to people working in the
broadcast industry.

The Working Group should consider providing greater flexibility in the
Media exemption to SC 1.1.1, while still retaining the overall desire
for text alternatives to be provided for television and radio
broadcast material that is re-presented on the web.

The Working Group might like to consider extending the Media exemption
to allow programs that are presented in "real-time" (e.g. daily radio
shows, sports broadcasts, current affairs tv) to contain a percentage
of "prerecorded" material (e.g. 25%) without the need to provide a
transcript for that material.

The Working Group might like to consider incorporating a
time-dimension into the Media exemption for SC 1.1.1. For example, a
text alternative for non-text content should be provided within 14
days. This would allow broadcasters sufficient time to prepare text
alternatives for substantial programs and would enable them to
continue to provide "streamed media on demand" for 14 days without the
need to include a text alternative.

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

Answering your questions in turn:

1)  No - the media exemption is not in response to any mainstream use
of media. It is meant for media alternatives to what is already on the
page where  the media alternatives are provided for accessibility
reasons.  This is defined if you click the link for the phrase "media
alternative for text" in the provision.   (note we changed
"alternative for text" to "media alternative for text" in the
provision)

2) Regarding terminology - we have now defined "live" and
"prerecorded".  These new definitions should address your 'sports' and
'unfolding news event' question as well.

3) Correct.  All broadcast streaming material would be time based.

4) We have reworded the 1.2 success criteria to remove the ambiguity.
If there is mixed live and prerecorded, each follows the guideline for
its type of media.  Although not required, it would of course be
preferred if the mixed media were to follow the more accessible
"prerecorded" rules.

5) With regard to 14 day exemptions and the like, those types of rules
are outside of the scope of WCAG.  WCAG is like a measuring stick. It
is used to measure the level of accessibility but not to state where
different levels should be applied.





----------------------------------------------------------
Comment 7: Provide no keyboard trap information in context
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0018.html
(Issue ID: 2394)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

In cases where moving focus away from a component with the keyboard is
relatively complex, this criterion requires users to be advised of a
method for doing this. However, neither the Success Criterion nor the
How to Meet and Understanding documents appear to suggest where or how
this advice should be provided. It would seem to be most appropriate
to offer the advice within the context of the component and in my view
providing the advice on a generic accessibility information page would
not be adequate.

Proposed Change:
Success Criterion rewritten as follows:

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component
of the page using a keyboard interface, then focus can be moved away
from that component using only a keyboard interface, and, if moving
focus away requires more than unmodified arrow or tab keys, a
mechanism is provided in conjunction with the component to advise
users how to move focus away. (Level A)

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

We have purposely not specified in the SC where the instructions would
need to be provided. It may be on the page. Or, for an application,
the instructions may appear at the front pages rather than being
repeated on hundreds of pages that are essentially identical in
operation, but gather different data.

----------------------------------------------------------
Comment 8: Essential Exception
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0019.html
(Issue ID: 2395)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

When it comes to time limits the Criterion requires at least one of a
number of conditions to be true. These include, "Essential Exception:
the time limit cannot be extended without invalidating the activity."
There appears to be no additional definition of what constitutes
"essential" or advice on interpreting this condition.

As it stands, it appears that it would be possible to declare that any
event maybe deemed to be invalidated by extending the time-limit.

Proposed Change:
The Working Group consider removing "Essential Exception" since it
would appear that all likely essential exceptions would already be
covered by the "Real-time Exception" condition.

If this is not possible, the Working Group should provide a precise
indication (with example) of what constitutes an Essential Exception.

Received on Tuesday, 22 January 2008 00:40

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

We have added a definition of essential that reads:

essential
 if removed, would fundamentally change the information or
functionality of the content, and information and functionality can
not be achieved in another way that would conform


----------------------------------------------------------
Comment 9: Changing SC for re-authentication after time limit expiration
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0020.html
(Issue ID: 2396)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Time limits can present problems for many people with disabilities and
these problems can be greatly exacerbated when a session expires and
data is lost. Currently this is a Level AAA Criterion.

Although moving this up to Level AA has been rejected before by the
Working Group, I don't believe the explanation offered in Point 2.2.6
of the Issues and Changes Summary document is sufficient to justify
keeping this Criterion at Level AAA.

Proposed Change:
Move SC 2.2.5 Re-authenticating up to Level AA.

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

Our apologies. In trying to keep the changes document short, we
shortened some of our rationales. Here is the full rationale for not
changing the level:

The working group has discussed this issue at length. The criteria for having
something at Level AA is that it must be something that can reasonably be
applied to all Web content.

But there are valid reasons, such as financial security or personal
information where this cannot be done because it is against
regulations to preserve any of this information once a session expires
or is terminated.

Also, this success criterion requires control of the server that may
not be possible for some authors and technologies.

It is also a new success criterion in WCAG 2.0 and there is little if
any experience with the requirement and the solutions.

For these reasons, the Working Group decided to put this requirement
at Level AAA.

----------------------------------------------------------
Comment 10: Change SC level for flashing content
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0021.html
(Issue ID: 2397)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Guideline 2.3.2, which relates to flashing content that is known to
cause seizures, contains two Success Criteria. The first, which is at
Level A, requires web pages to have no content that flashes more than
three times in one second or the flash is below defined "general flash
and red flash thresholds". The second criterion, which is at Level
AAA, requires web pages not to contain anything that flashes more than
three times a second.

When it comes to determining the "general flash and red flash
thresholds" the amount of screen that the flashing content can occupy
is precisely defined in one sense, however there appears to be an
assumption that typical viewing involves a display area of 1028 x 768
pixels and a viewing distance of 56-66 cm. The Understanding SC 2.3.1
document does not appear to provide any advice or examples for meeting
the needs of users with impaired vision who do not conform to these
typical viewing conditions.

For screen magnifier users it is not uncommon for the entire display
area to occupy less than 25% of a typical 1028 x 768 screen. Also, the
field of view for people with tunnel vision or other vision
impairments is often very different to the "typical". For these
people, the combined area of flashing content that is deemed
acceptable under the "general flash and red flash thresholds" may well
be excessive.

Given that Guideline 2.3 recognises certain flashing content is a
known to cause seizures, I believe WCAG 2.0 should provide greater
support for people with impaired vision who might also be at risk of
seizures, and give greater guidance to developers in how to minimise
this risk.

Proposed Change:
Move SC 2.3.2 Three Flashes up to Level AA.

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

Success Criterion 2.3.2 bans many things including video of natural
phenomenon (e.g. lightning strikes) common video occurrences  (sun
shining through a row of trees) and some movie effects (any machine
gun) even if they are small or muted.   As such, it is quite
restrictive of content.  The group did not feel that it should be at
level AA.



----------------------------------------------------------
Comment 11: labels and headings definition not sufficient
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0022.html
(Issue ID: 2398)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

The text of this criterion is, "Labels and headings are descriptive.
(Level AA)." This definition is too short and does not sufficiently
describe the intent of the criterion.

Proposed Change:
The Working Group should consider rewriting SC 2.4.6. For example;

2.4.6 Descriptive Labels and Headings: Labels and headings are
descriptive and allow the relationships between the different sections
of web page content to be easily determined. (Level AA)

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

We have clarified SC 2.4.6 to read: "2.4.6 Labels Descriptive:
Headings and labels describe topic or purpose."

We have added the following sentences to Understanding 2.4.6 "Labels
and headings do not need to be lengthy. A word or even a single
character may suffice if it provides an appropriate cue to finding and
navigating content."

----------------------------------------------------------
Comment 12: provide greater support for people with cognitive,
language or reading difficulties
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0023.html
(Issue ID: 2399)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Like many others, I have argued in the past that WCAG 2.0 does not
provide sufficient formal recognition of the importance of meeting the
needs of people with cognitive, learning or language limitations. I
believe this is still the case with the current Last Call Draft.

Given the Working Group's obsession with testability when it relates
to Success Criteria concerned with cognitive and learning difficulties
(a requirement that does not appear to be so fervently demanded when
it comes to other disabilities), I recognise that the Working Group is
never going to accept a general notion that web content should use
clear and simple language that is appropriate to the needs of the
audience (similar to WCAG 1.0 " 14.1).

However, within Guideline 3.1, I feel that more should be done to help
ensure that people with cognitive, learning or language difficulties
are able to access web content which can directly affect their health
and liberty.

The "Understanding SC 1.2.1 Captions" document appears to recognise
that at least some "legal documents" and "instructional manuals" might
need to contain non-text synchronised media in order to assist
comprehension, however there is no explicit requirement to include
this material. While the issue of ensuring text equivalents are
provided for non-text content is well catered for in WCAG 2.0, very
little is done to ensure assistance is provided for web users who have
difficulties reading or interpreting text.

The following suggested Success Criterion draws on the apparent
acknowledgement in SC 3.3.4 that, with some web content the potential
consequences of inaccessibility are greater. Even though I am not
comfortable with the idea of associating cognitive, learning and
language difficulties with reading ability, the suggested criterion
uses the readability of "lower secondary education level" as a
yardstick since it appears that this provides a degree of testability
that is acceptable to the Working Group.

Proposed Change:
The Working Group should consider including the following new Level A
Success Criterion for Guideline 3.1:

3.1.* Understandable (Legal, Financial, Health): For Web pages that
provide legal, financial and health instructions, warnings or
regulations that are essential for the preservation of the
individual's health and liberty, at least one of the following is
true: (Level A)

1. Readable: The text does not require a reading ability more advanced
than lower secondary education level.

2. Text alternative: An alternative simple language version with
equivalent information that does not require a reading ability more
advanced than lower secondary education level is also provided.

3. Non-text alternative:  An alternative non-text version (for example
audio or video) that contains equivalent information is also provided.

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

We looked at this very carefully but the working group does not feel
that it can require that legal documents, for example, can be required
to be easy to read.   There are many reasons for the language used in
these types of documents.  Also it is often not legal to have an
alternate form of the document that a person would read that is
different from what they are agreeing to.

Regarding the audio form, we do require at level A that all documents
have a text form that is readable by assistive technologies.   There
are also free utilities on the web and built into popular operating
systems that will read a text document aloud.
Received on Tuesday, 11 March 2008 00:21:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:25 GMT