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

Your comments on WCAG 2.0 Last Call Draft of April 2006 (2 of 3)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:34:36 -0700
Message-ID: <824e742c0705171634j53beaefma3b18196ac1aab23@mail.gmail.com>
To: "Greg Lowney" <gcl-0039@access-research.org>
Cc: public-comments-WCAG20@w3.org

Comment 15:

Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1160)

1.3.5 says information required to operate the content should not rely
on visual location or orientation of components, but in HTML forms the
association between a control (e.g. radio button) and its visual label
(e.g. static text nex to it) are only exposed programmatically through
the DOM and visually by the spatial relationship between the two
objects. The only way to avoid relying on spatial cues is to use
assistive technology; is that the intention of this criterion, even
though the word "programmatically" does not appear in the wording and
the Understanding and Techniques don't explicitly mention steps to
assist assistive technology?

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

The success criterion has been reworded to make it clear that it is
about instructions to the user that use spatial referents. Form labels
are therefore excluded from the requirements of this SC.

----------------------------------------------------------
Comment 16:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1161)

1.4.1 specifies a minimum luminosity contrast between text or diagrams
and their backgrounds. Often diagrams include portions that convey
information and other portions that are purely decorative; in such
cases, shouldn't this criterion apply only to portions of the text or
diagram that are functional or convey information? Large text used as
a decorative element behind the text of a Web page is an example of
purely decorative text, and in such cases you really need to retain
low contrast with the background.

Proposed Change:

Change to read "Portions of text or diagrams that are not purely
decorative have a luminosity contrast ratio of at least 5:1 when
compared with their backgrounds."

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

The topic of contrast in diagrams became so complicated and uncertain
that diagrams were removed from the provision. It now only applies to
text and images of text.

RE: Decorative text, we do not require that decorative text need be
high or low contrast. Just that there be sufficient contrast between
non-decorative text and what is immediately around it. If the
background of non-decorative text contains decorative text the
contrast provision would apply. If not, we have no restrictions on it.

----------------------------------------------------------
Comment 17:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1162)

1.4.2 requires a mechanism to turn off "background audio that plays
automatically, without requiring the user to turn off all audio". This
is good except that "background audio" is not defined. Is it audio
that is played at the same time as other audio, but is considered to
be less important (i.e. background behind other audio)? Or Is it audio
that is purely decorative and/or atmospheric, but not required for
understanding or use of the web unit (regardless of whether other
audio is playing)?

Proposed Change:

Define "background audio", or change "background audio" to either
"audio" or "purely decorative audio".

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

Good point. We have revised the success criterion 1.4.2 to read,
"1.4.2 If any audio plays automatically for more than 3 seconds,
either a mechanism is available to pause or stop the audio, or a
mechanism is available to control audio volume which can be set
independently of the system volume."

----------------------------------------------------------
Comment 18:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1163)

1.4.4 Note uses the phrase "four times (4x) quieter", but that seem a
meaningless term. One can only talk about something being "four times
louder" because loudness is measured relative to the absence of
audible sound. "Four times quieter" would only make sense if noise A
is compared with some other, even louder sound.

Proposed Change:

Change to read "Background sound that meets this requirement will be
approximately one quarter as loud as the foreground audio content."

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

We have updated the note to read, "Background sound that meets this
requirement will be approximately one quarter as loud as the
foreground speech content."

----------------------------------------------------------
Comment 19:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1164)

2.1.1 requires all functionality of the content to be operable in a
non-time-dependent manner through a keyboard interface. However, many
Web sessions eventually time out, and there is no practical way to
design the server software to avoid this. Even when the Web content
complies with criterion 2.2.1 and 2.2.6, which in many cases requires
the user have some control over such time-outs, that does not make it
comply with 2.1.1.

Proposed Change:

Define "non-time-dependent manner" as "method that does not require
user action within any period shorter than ten minutes", or else add a
Note to 2.1.1 explaining that server-based session time-outs of at
least some minimum duration are not considered part of the content.

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

Time-outs are covered under another success criterion.  This refers to
not requiring individual keys to be pressed or released under
particular time contraints. To make this clear, we have rewritten the
SC to
2.1.1  All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual
keystrokes, except where the underlying function requires input that
depends on the path of the user's movement and not just the endpoints.

----------------------------------------------------------
Comment 20:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1165)

2.2.1 Is there a difference between a "time-out" and a "time limit"?
The title refers to "time limits" but the wording of the SC uses
"time-outs" in all but one instance.

Proposed Change:

Change "time-out" to "time limit" throughout 2.2.1.

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

We have updated SC 2.2.1 to use the term "time limit" instead of "time-out".

----------------------------------------------------------
Comment 21:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1166)

2.2.1 applies to each time-out "that is a function of the content".
Does that include time-outs that are applied by the server software,
and of which the Web unit may have no knowledge (e.g. session timing
out from inactivity)? Clarification is needed. The Understanding
document addresses this but fails to clarify it, but it looks like
server-based session time-outs would be non-conforming.

Proposed Change:

"Remove the phrase ""that is a function of the content"".

Add clarification of server-based session time-outs to the
Understanding document or the SC itself."

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

The Success Criterion has been changed to clarify that it was intended
that only time limits set by the content are in scope, and additional
clarification has been added to the How to Meet document.

----------------------------------------------------------
Comment 22:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1167)

Is it intended that ticket purchasing Web sites fail to conform
because they only give the user two minutes to confirm a purchase
before the seats are returned to the general pool and the user must
start the process over again? If you don't want that fail, which of
the exceptions would it fall under? (I don't see it falling under any
of them as currently written.) If you do want it to fail, what would
you recommend such sites do in order to become compliant, allow the
user to extend the time limit up to a maximum number of times? This
would be a good example to add.

Proposed Change:

Add to Understanding of Techniques an example of a ticket-purchasing
Web site that allows the user two minutes to confirm purchase of
selected seats, but warns the user when their time is almost out and
allows the user to extend this time limit some number of times with a
simple action such as clicking a "Extend time limit" button.

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

Ticket purchasing Web sites in which tickets must be purchased quickly
and cannot be held indefinitely would fall under the exception in the
final bullet, in which the timeout is essential and cannot be extended
without invalidating the activity. We have added an example to clarify
this, and indicated that there could be ways to minimize the
accessibility barrier provided. We also provide an example to indicate
that tickets whose sale are not time sensitive do not fall under this
exception.

----------------------------------------------------------
Comment 23:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1168)

2.2.2 requires content to not blink for more than three seconds or a
method be available to stop all blinking in the Web unit or authored
component. Many Web sites display GIF images that are provided by a
third-party (e.g. advertisements, or user-contributed photos); are
such sites required to ensure that none of those are animated GIFs, in
case some blink? Is it sufficient for the authors to define a baseline
that includes user agents that allow the user to stop blinking on the
current Web unit (e.g. pressing ESC)?

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

You ask two questions:
1)Yes, aggregators are responsible for the content they aggregate. If
the aggregator wants to claim conformance at level AA, there must be
no third party images integrated into the content which violate this
success criterion.
2)It would be sufficient to use a technology for which user agents are
available which allow the user to freeze the technology (as is the
case of GIFs). This is the 2nd sufficient technique under SC 2.2.2.

----------------------------------------------------------
Comment 24:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1169)

2.2.3. requires that content can be paused by the user (barring
certain exceptions). Pausing, as opposed to Stopping, implies there is
UI to un-pause the content. Would it be acceptable to allow decorative
content to be stopped, but not provide UI to resume it? The current
wording would preclude that.

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

The success criterion has been modified as you suggest to allow moving
content that is pure decoration to simply be stopped without requiring
a means to restart it.

----------------------------------------------------------
Comment 25:

Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14
(Issue ID: LC-1170)

2.5.3 option 3 is that the user is able to review and confirm or
correct information before submitting it. However, in almost all cases
the user can pause after entering data, and review it before pressing
ENTER or clicking SUBMIT, etc. I believe the intent of this option is
that pressing ENTER or clicking SUBMIT should bring up a new Web unit
that displays how the system interpreted what the user wrote (as
opposed to what they thought they were writing). If so, shouldn't the
wording make this clearer?

Proposed Change:

Change to read "The user is able to have the information they entered
re-presented to them so they may review and confirm or correct it
before final submission."

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

The third bullet has been rewritten to make it clear that the user has
the opportunity to review the results being submitted before
confirming the transaction.

The item now reads, "A mechanism is available for reviewing,
confirming, and correcting information before finalizing the
transaction."


----------------------------------------------------------
Comment 26:

Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1171)

2.5 3 requires, for Double-A, that methods are provided to help avoid
or undo errors, but only for a certain narrowly-defined set of
interactions. I would recommend that these steps, or at least UNDO, be
repeated as a level 3 success criterion, but applying to all
interactions rather that just those listed in 2.5.3.

Proposed Change:

Add a new Level 3 success criteria:
2.5.5 For all user actions, at least one of the following is true:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next
step in the process.
3. The user is able to have the information they entered re-presented
to them so they may review and confirm or correct it before final
submission.

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

Thank you for your suggestion. The working group has determined that
"all" user actions is too broad. For example, these techniques would
not be appropriate for the action of logging out of a secure banking
site or selecting a link that closes a window.

However we've adopted it to a narrower focus of forms at Level AAA.
Here is the language:

3.3.6: For forms that require the user to submit information, at least
one of the following is true:
   1. Reversible: Transactions are reversible.
   2. Checked: Submitted data is checked for input errors before going
on to the next step in the process.
   3. Confirmed: A mechanism is available for reviewing, confirming,
and correcting information before finalizing the transaction.

----------------------------------------------------------
Comment 27:

Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1172)

4.1.1 requires that Web content to be parsed unambiguously. Does this
require the formal specifications be open, so that new user agents can
parse the content? For example, suppose the baseline specifies just
one Web browser, that implements rules for applying defaults to
resolve any potential ambiguities in HTML that might be interpreted
differently if another browser were used; is the HTML parsable
unambiguously within the scope of the baseline? As another example,
suppose a Web uses a proprietary data format that only a single
plug-in can render; does it matter if it's parsable unambiguously if
there is only one renderer?

Proposed Change:

Insert the phrase ", using publicly available specifications", to read
"Web units or authored components can be parsed unambiguously, using
publicly available specifications, and the relationships in the
resulting data structure are also unambiguous.

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

To make this requirement easier to understand, we have reworded SC
4.1.1 to clarify that it must be possible to parse content without the
need for user agent repair. The revised SC reads as follows:

4.1.1 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.
(Level A)

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.

----------------------------------------------------------
Comment 28:

Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1173)

4.1.2 includes the phrase "available to user agents, including
assistive technologies", but other criteria say "available to user
agents" without the "including assistive technologies". The phrase is
not strictly required since we define user agents as including
assistive technologies; you may feel it's useful to re-emphasize that
here, but if that's the case, wouldn't it also be warranted in those
criteria that say "programmatically..." by adding "including assistive
technology" to the definitions of programmatically set and
programmatically determined?

Proposed Change:

Delete the phrase ", including assistive technologies", to read "For
all user interface components, the name and role can be
programmatically determined, values that can be set by the user can be
programmatically set, and notification of changes to these items is
available to user agents."

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

Although the definition of user agent includes assistive technologies,
the definition blurs the distinction between support for users with
disabilities that is provided directly by the user agent and support
that is provided by an external service that interacts with a user
agent that does not provide that support directly. Within WCAG, we use
assistive technology to refer to the latter sort of service. We call
out support for assistive technology explicitly so that
programmatically determinable information is available to assistive
technology, and not just to the host user agent.

In SC 4.1.2, it is a particularly important distinction for the
notification of changes to user interface components. Information can
be programmatically determined without requiring notification of
changes. This would require constant polling of the content to notice
changes. For many technologies, the host user agent is implementing
the change, so it is automatically notified, but assistive technology
needs explicit notification.

----------------------------------------------------------
Comment 29:

Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1174)

4.2.2. says that if the user can enter content using the keyboard they
must also be able to exit it using the keyboard, even if the content
uses a non-baseline technology. This helps, but is not a complete
solution, because it does not require that the keyboard method be
discoverable by the user, especially if the user has a disability
(e.g. a screen that cannot be read by a screen reader displays "text"
telling the user they can exit by pressing F10, but the user who
relies on the screen reader has know way of figuring that out). This
is addressed in Techniques, but I fear that is inadequate because such
documentation is so critical.

Proposed Change:

Change "If content can be entered using the keyboard, then the content
can be exited using the keyboard." to read: "If content can be entered
using the keyboard, then the content can be exited using the keyboard,
and the method for doing so is described using technology in the
baseline."

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

Thank you for the suggestion. We have modified the success criterion
to address the issue that you raised:  If focus can be moved to
technologies that are not accessibility supported using a keyboard
interface, then focus can be moved away from that content using only a
keyboard interface, and the method for doing so is described before
the content is encountered and in a way that meets all Level A success
criteria."
Received on Thursday, 17 May 2007 23:34:53 UTC

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