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

Comment 60:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1085)

Level 1: There should be Level 1 equivalents of 1.4.1 and 1.4.2.

Proposed Change:

Create new SC or move 1.4.1 and 1.4.2 to Level 1

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

Because background audio can interfere with assistive technology, SC
1.4.1 (formerly 1.4.2) has been moved to level A.

Because level A attempts to put the fewest possible limitations on
presentation, and because assistive technology will be able to present
the text or text equivalents of this content to the user, the working
group felt that SC 1.4.2 (formerly 1.4.1) was most appropriate at
level AA.

----------------------------------------------------------
Comment 61:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1086)

Intent: Add to the intent that people with Parkinson's disease find
using a mouse very difficult and therefore usually use a keyboard

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

We have added the following to 2.1.1. benefits.
"Some people with hand tremors find using a mouse very difficult and
therefore usually use a keyboard"

----------------------------------------------------------
Comment 62:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1087)

Intent vs Benefits: These two sections are essentially the same

Proposed Change:

Either differentiate the two sections more, or merge them

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

We have combined these two sections.


----------------------------------------------------------
Comment 63:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1088)

Situation A: In this situation clarify whether scripts are part of
baseline or not

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

Baseline has been changed to "Accessibility-supported Web
technologies". This is used when making a conformance claim and is not
part of each individual success criterion.  The How to Meet documents
for each success criterion provide techniques using different
technologies which may be used to meet the criterion. The techniques
selected to satisfy the success criterion are sufficient as long as
they only rely on features of technologies that are
accessibility-supported

WCAG 2.0 provides a set of rules for evaluating whether a technology
is accessibility supported, but does not specify whether particular
technologies are or are not accessibility supported. The reason for
this is that accessibility support for various technologies is in a
constant state of change as new technologies are introduced and
support improves for existing technologies. Whether Script is
accessibility supported for a particular project would be determined
by a variety of factors described in the section " Accessibility
Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .

----------------------------------------------------------
Comment 64:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1089)

Example B: automatic updates are not timeouts.

Proposed Change:

Remove this example from this SC

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

The Working Group views automatic updates, which happen after a set
amount of time or on a periodic basis, to be time-outs and intended
that case to be covered by this success criterion. This may not have
been clear so we have added the following content to the How to Meet
2.2.1 document:

Any process that happens without user initiation after a set time or
on a periodic basis is a time-out. This includes partial or full
updates of or changes to content, or expiry of a window of opportunity
for a user to react to a request for input.

----------------------------------------------------------
Comment 65:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1091)

Script: The techniques and examples are very script heavy. It appears,
to a casual reader, that the W3C is advocating scripting above other
technologies, such as PDF, XHTML or CSS.

Proposed Change:

Ensure that techniques and examples are evenly spread over a variety
of technologies

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

The examples have to match the technologies. The scripting examples
are only used where we are trying to demonstrate dynamic content.
Scripting is the most common method for this.  If you have other
examples you think could be included, please submit them.  We are
always looking for additional good examples.

----------------------------------------------------------
Comment 66:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1092)

Example - A stock ticker: In this example it specifies that stocks
updated during the pause will not be shown. This sounds like showing
the stocks updated during the pause is outlawed.

Proposed Change:

Change the text to "Stocks updated during the pause may or may not be
displayed, depending on the interface."

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

Thank you for pointing out the flaws in this example. It was also
pointed out by another reviewer that the sufficient technique for this
success criterion requires paused content to be restarted from the
point where it was stopped but with a notice that the display is
delayed. This example has been modified to say the ticker will restart
from the point where it was paused so that all trades that occurred
while it was paused will be displayed.

----------------------------------------------------------
Comment 67:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1093)

Example - A stock ticker: Doesn't this example violate 1.1.1? If
someone stops the stock ticker and therefore misses out on some
information shouldn't that information be provided elsewhere?

Proposed Change:

Clarify example

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

Thank you for pointing this out. It was also pointed out by another
reviewer that the sufficient technique for this success criterion
requires paused content to be restarted from the point where it was
stopped but with a notice that the display is delayed. This example
has been modified to say the ticker will restart from the point where
it was paused so that all trades that occurred while it was paused
will be displayed.

However, if a control to turn off (rather than pause) the presention
of real-time information via non-text content (ex. an applet) were
present, there would be no requirement that the information that was
not displayed during the time it was turned off would be available.

----------------------------------------------------------
Comment 68:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1095)

Example - A questionnaire with a timeout: In this example, there are
several recommendations that certainly would make the questionnaire
more accessible (alert popups, information on timeout etc) but these
do not actually relate to this (or any) SC. These are excellent
requirements - they should be developed into SC

Proposed Change:

Create new SC (I am happy to help with this)

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

This example illustrates the use of techniques for both 2.2.6 and
2.2.1. To make this clear, we have added a note that reads, "Refer to
[Techniques for Addressing Success Criterion 2.2.1] for techniques
related to providing notifications about time-outs." to the listing of
sufficient techniques in 2.2.6.

----------------------------------------------------------
Comment 69:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1096)

2.2.6: This should be at Level 2. If someone is using an authenticated
session and cannot complete the information before automatic logoff,
then being able to continue after re-login is imperative in order to
use the system. Otherwise the system is inaccessible

Proposed Change:

Move 2.2.6 to Level 1

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

The working group has discussed this issue. 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. The working group therefore
decided to put this requirement at Level AAA.

----------------------------------------------------------
Comment 70:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1097)

Example - A questionnaire with a timeout: In this example, there are
several recommendations that certainly would make the questionnaire
more accessible (alert popups, information on timeout etc) but these
do not actually relate to this (or any) SC. These are excellent
requirements - they should be developed into SC

Proposed Change:

Create new SC (I am happy to help with this)

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

This example illustrates the use of techniques for both 2.2.6 and
2.2.1. To make this clear, we have added a note that reads, "Refer to
[Techniques for Addressing Success Criterion 2.2.1] for techniques
related to providing notifications about time-outs." to the listing of
sufficient techniques in 2.2.6.

----------------------------------------------------------
Comment 71:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1098)

Flash: Where is the research that underpins the decision to allow
flashing within certain areas on a screen?  How were these values
decided?

Proposed Change:

Clarify the SC

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

This decision is based on the existing seizure disorder research and
the broadcast industry guidelines in place in several countries.  It
is primarily based on the work of Jeavons and Harding and on the
guidelines developed in UK and used elsewhere.   References to the
research are available from the resource links provided in the How to
Meet and the techniques documents.

----------------------------------------------------------
Comment 72:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1099)

Techniques: Add a technique to turn the flash off before it begins

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

Thank you for this suggestion for a new technique. We have created it
and added it as an advisory technique for 2.3.1. This can't be a
sufficient technique because that would be less than what is required
by the success criterion, which is that there is no content that
violates red or general flash thresholds.


----------------------------------------------------------
Comment 73:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1100)

Seizures: This is a Level 3 SC yet the Intent specifies that it is
intended not to cause seizures.

Proposed Change:

Clarify the SC. If it is intended not to cause seizures it should be at Level 1.

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

The primary seizure provision is already at Level A.  This provision
is an extra measure that can be taken for those who want to go above
and beyond.  It covers all flashing including very small areas of the
screen that would not be sufficient to cause problems.  The purpose is
to allow users to use extreme magnification and still not have a
problem.  This goes beyond all current standards.

----------------------------------------------------------
Comment 74:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1101)

Examples: The example in SC 2.3.1 (Level 1) specifies two lightning
flashes, whereas the example in SC 2.3.3 (Level 3) specifies three
lightning flashes. A level 3 SC should have less flash than a Level 1
SC

Proposed Change:

Rewrite the examples or the SC

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

Good catch. The example for SC 2.3.1 has been rewritten as two
examples.  One with flashing in a small area, and one that matches the
SC 2.3.2 example to show that using the tighter SC 2.3.2 criterion is
sufficient for Level A. The new SC 2.3.1 example reads:
"Example 1:  Web site has video of muzzle flash of machine gun fire
but limits the size of the flashing image to a small portion of the
screen below the flash threshold size."

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