RE: Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 3)

Hello,

My apologies taking so long to get back to you.

First, I'd like to thank the working group and congratulate them on a very
fine document. I'm very impressed by many of the improvements in this draft,
both in content and in formatting, particularly the use of concise titles
for each item and the more compact layout of key sections.

I'm quite satisfied by most of the working group's responses to my earlier
comments, although a few follow-up questions or suggestions are included
below and indicated by "{Greg Lowney 6/28/07: ... }"

In addition, included at the bottom of this email are 15 new comments on
this draft, and one related comment on the accompanying Understanding
document.

All of this is also included as a Word document, with revision marks helping
to highlight my comments.

	Thanks,
	Greg Lowney

From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
Sent: Thursday, May 17, 2007 3:34 PM
To: Greg Lowney
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 3)

Dear Greg Lowney ,

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/001501c59b26$aaec1bb0$6800a8c0@lucky13
(Issue ID: LC-1146)

"Grouping blocks of repeated material in a way that can be skipped
USING one of the technology-specific techniques below (for a
technology in your baseline)" is ambiguously worded due to a dangling
participle. I read it at first as equivalent to saying
"Group blocks of repeated material, using a method that can be skipped
using the techniques."

Proposed Change:

Insert a comma so it reads
"Grouping blocks of repeated material in a way that can be skipped,
USING one of the technology-specific techniques below (for a
technology in your baseline)"

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

The draft has been updated as proposed.
{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 2:

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

In " Techniques for Addressing Success Criterion 4.2.1", the ordered
list of three items has "OR" between items 1 and 2, but nothing
between items 2 and 3 to clarify their boolean relationship.

Proposed Change:

Insert "OR" at the end of bullet item 2.

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

We agree. However, the third item in this list has been removed as
part of a resolution to another issue, so the need for an additional
"OR" here is no longer present.
{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 3:

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

"The Conformance section and SC 4.2 clearly contradict each other. The
section on Conformance currently reads ""WCAG 2.0 conformance at level
A means that all Level 1 success criteria in the guidelines are met
assuming user agent support for only the technologies in the specified
baseline."" By contrast, 4.2.1 and 4.2.3  say ""At least one version
of the content meets all level N success criteria, but alternative
version(s) that do not meet all level N success criteria may be
available from the same URI.""

Take for example a URI that has two versions of the same content, one
not meeting SC 1.1.1 and the other an accessible alternative that does
meet 1.1.1. Can that URI conform at Single-A? Under the current
wording of the Conformance section, the answer is clearly NO! That
page complies with 4.2.1 (by providing an accessible alternative), but
it still fails 1.1.1: the rules stated in the Conformance section
provide no exemption from 1.1.1 just because something passes 4.2.1,
nor does 1.1.1 itself define any such exemption.

If conforming with 4.2.1 is meant to provide exemptions from most
other Level 1 criteria, the document MUST say that in the normative
Conformance section or in the description of each success criterion.

You might say that the intent is understood, but the question is, is
the intent supported or contradicted by the actual wording of the
normative sections of the document?"

Proposed Change:

"Change Conformance to explicitly say that conformance requires that
each URI conforms with all SC of the appropriate level OR that an
accessible alternative that does so is available from the same URI
(with a link to the details of what that means, currently in the
Understanding document's discussion of Guideline 4.2).

OR, change the section ""Conformance Levels and the Baseline"" to say
that only conformance with criterion 4.2.1 is required to claim
Single-A conformance, and leave it to 4.2.1 to require all the rest of
the Level 1 criteria."

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

We have moved the requirements of success criterion 4.2.1 out of the
guidelines and into the conformance section, and we have changed the
definition of the conformance levels to require that each web page
either satisfy all success criteria at that level or satisfy the
alternate version requirement.
{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 4:

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

This is closely related to the previous comment on Conformance, and a
follow-up to existing issue 1590.

I was unable to spot where, in the Conformance section or elsewhere,
it is made explicit whether success criteria need to be met all the
time, or by default, or only on request. For example, 1.4.1 says
""Text or diagrams, and their backgrounds, have a luminosity contrast
ratio of at least 5:1""; is it acceptable if that is a user-selectable
option, and if so, does it have to be on by default? The closest I can
find to addressing this is Guideline 4.2, ""Ensure that content is
accessible or provide an accessible alternative,"" under which SC
4.2.1 (for example) says ""At least one version of the content meets
all level 1 success criteria, but alternate version(s) that do not
meet all level 1 success criteria may be available from the same
URI."" This can be taken as making it clear that all success criteria
can be met at the user's request, and do not need to be met in the
default configuration. However, it seems strange to have success
criteria in one guideline (4.2) effectively define exceptions to every
other success criteria in the document, essentially saying ""You know
that thing we said you have to do? Well, you don't have to do it under
certain circumstances."" As a result, 4.2.x are the only success
criteria that are actually required; the rest are all conditionally
required, although you won't find this out unless you read 4.2.

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

We have moved the requirements on alternate versions from guideline
4.2 to the conformance section. The current wording should clarify
that inaccessible versions are permitted, but only if they provide an
accessible mechanism to reach an accessible version:

Alternate Versions: If the Web page does not meet all of the success
criteria for a specified level, then a mechanism to obtain an
alternate version that meets all of the success criteria can be
derived from the nonconforming content or its URI, and that mechanism
meets all success criteria for the specified level of conformance. The
alternate version does not need to be matched page for page with the
original (e.g. the alternative to a page may consist of multiple
pages). If multiple language versions are available, then conforming
versions are required for each language offered.

{Greg Lowney 6/28/07: Seems reasonable, but it "or its URI" means that it
may be up to the user or user agent to, say, change ".html" to "-text.html",
or, say, change "http://domain.com/products/prod1.htm" to
"http://domain.com/cgi-bin/textonly.pl?category=products&item=prod1" Is it
your intention that those be acceptable?}

----------------------------------------------------------
Comment 5:

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

The paragraph defining "user agent" implies that it incldues all AT,
whereas it really only includes some AT. It reads: "It is important to
note that assistive technologies are included in this definition.
Assistive technologies include screen readers, screen magnifiers,
on-screen and alternative keyboards, single switches, voice
recognition, and a wide variety of input and output devices that meet
the needs of people with disabilities."

Proposed Change:

Add phrases shown in upper case: "It is important to note that MANY
assistive technologies are included in this definition. SUCH assistive
technologies include screen readers, screen magnifiers, on-screen and
alternative keyboards, single switches, voice recognition, and a wide
variety of input and output devices that meet the needs of people with
disabilities."

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

We removed this paragraph because it was redundant with the
definitions and we were removing unnecessary informative information
from the conformance section. We have clarified the relationship
between user agents and assistive techologies in the current
definitions.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 6:

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

The example conformance claims are invalid because they omit the full
name and URI of the guidelines, which are required according to the
section "Required components of a conformance claim".

Proposed Change:

Replace "W3C's WCAG 2.0" with "Web Content Accessibility Guidelines
2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/"

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

The draft has been revised as proposed.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 7:

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

One required component of a conformance claim is "Scope of the claim
(a URI, list of URI's, or a set of URIs defined by a regular
expression)," and the examples each include a single URI. This, the
Examples, and the Conformance Notes all fail to clarify whether citing
a single URI implies conformance is claimed for that one web page (or
equivalent), or all pages referenced by it, or all pages "beneath it"
on the server. For example, does claiming conformance for
http://telcor.example.com/nav/G7/intro.html mean that conformance is
claimed just for that one page, or for all the pages it links to, or
all the pages in the /nav/G7/ directory on the server, including or
not including subdirectories? I suggest clarifying this and also
including an example of a claim for an entire Web site or multi-page
portion thereof.

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

We have completely rewritten the Conformance section. The format of
this description is no longer specified. The corresponding required
component is now:

4. A description of the URIs that the claim is being made for,
including whether subdomains are included in the claim.

We have fixed the existing examples to clarify that the first applies
to the entire site and the second applies only to the specific page.
We have added examples to illustrate the use of boolean and regular
expressions in a conformance statement.
{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 8:

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

The example conformance claims list things like jpeg as
'specifications that this content "relies upon"'. How can jpeg ever be
a relied upon specification since the guidelines require Web pages to
be usable even when the images are turned off?

Proposed Change:

Remove JPEG from list of "specifications that this content relies
upon", or else clarify what is meant by including it.

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

"Relies upon" means that it is used in this content and must be
supported by the user agent in order to claim conformance. If jpeg
were used to satisfy SC 3.1.5 by providing an illustration as
supplemental content, then jpeg would be relied upon.

{Greg Lowney 6/28/07: OK. Confusing, and possibly misleading, but I can live
with it.}

----------------------------------------------------------
Comment 9:

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

The guidance says that when referencing WCAG 2.0 with its full name
and URI, a period should be used after the date and before the
parenthetical URI. However, this is not how it's shown in the
Examples. I suggest removing the period from the guidance and leaving
the examples as they are.

Proposed Change:

Remove period after date, to read: "Web Content Accessibility
Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month
Year (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/, Latest version
at http://www.w3.org/TR/WCAG20/)"

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

The draft has been updated as proposed.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 10:

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

In the phrase "different forms are provided to accommodate multiple
disabilities", the word "multiple" could be read as saying these forms
should address the needs of an individual with multiple disabilities,
which is a nice goal but not the baseline requirement.

Proposed Change:

Change "different forms are provided to accommodate multiple
disabilities" to "different forms are provided to accommodate
different disabilities".

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

The bullet has been revised to read:

If the purpose of non-text content is to confirm that content is being
accessed by a person rather than a computer, then text alternatives
that identify and describe the purpose of the non-text content are
provided and alternative forms in different modalities are provided to
accommodate different disabilities

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 11:

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

The order of the two clauses is reversed from all the other success
criteria for guideline 1.2.

Proposed Change:

Change
"For prerecorded multimedia, a full multimedia text alternative
including any interaction is provided" to read
"A full multimedia text alternative including any interaction is
provided for all prerecorded multimedia."

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

We revised the term to "full text alternative for multimedia including
any interaction." The success criterion has been updated to read,
"1.2.7 A full text alternative for multimedia including any
interaction is provided for all prerecorded multimedia."

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 12:

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

The phrase "visually evident without color" could be misinterpreted as
meaning "visually evident, and without color". Suggest rephrasing to
be less ambiguous.

Proposed Change:

Change "visually evident without color" to read "visually evident even
if any color cannot be perceived".

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

SC 1.4.1 (formerly 1.3.2) has been revised to read:

Use of Color: Any information that is conveyed by color differences is
also visually evident without the color differences.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 13:

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

The guideline reads, "Any information that is conveyed by color is
also visually evident without color." This wording clearly implies
that it is acceptable to convey information by contrast, a technique
that is discussed in other criteria but overlooked both here and its
Understanding. Is the intent here to make sure information is visually
evident without perceiving color and contrast, or to say that
conveying information by contrast alone is acceptable? I suspect the
former. If the latter, we should provide guidance for 1.3.2 on minimum
acceptable contrast between items when color/contrast is used alone to
denote differences in type, state, etc., just as we do for differences
between foreground and background elsewhere. Even if the former, such
guidance on the use of contrast would be valuable as a Level 2 or
Level 3 criterion.

Proposed Change:

Change to read "Any information that is conveyed by color or contrast
is visually evident even if any color and contrast cannot be
perceived.."

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

We have combined SC 1.3.1 and 1.3.4 into a level A criterion that
reads, "1.3.1 Information and relationships conveyed through
presentation can be programmatically determined or are available in
text, and notification of changes to these is available to user
agents, including assistive technologies." We have also revised SC
1.3.2 to read, "1.4.1 Use of Color: Any information that is conveyed
by color differences is also visually evident without the color
differences."

The working group believes that the revised level A criterion
addresses your concerns regarding the use of conveying information via
contrast alone.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 14:

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

The wording "When the sequence of the content affects its meaning,
that sequence can be programmatically determined" is ambiguous as to
whether it refers to intended viewing/reading order, keyboard
navigation order, presentation order (e.g. navigation links are at the
top despite the designer's intention that they not be actually read on
every page), and/or declaration order (e.g. content is declared early
in the HTML despite being positioned at the bottom of the page using
vertical alignment attributes). The Understanding section only
addresses conveying intended reading order, but if that is the
intention, the wording of the Success Criterion should reflect that.
However, other ordering may be important to some types of assistive
technology (e.g. keyboard navigation order for use by speech
recognition software).

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

Yes, it is the intent that SC 1.3.2 (formerly 1.3.3) cover only
reading order. Keyboard navigation order is covered under SC 2.4.3
(formerly 2.4.6). The other aspects of the comment - presentation
order and declaration order are considered to be aspects of or
sufficient techniques for the above two issues. To clarify this, SC
1.3.2 was reworded: "When the sequence in which content is presented
affects its meaning, a correct reading sequence can be
programmatically determined  and sequential navigation of interactive
components is consistent with that sequence."

{Greg Lowney 6/28/07: Realistically, is there any content consisting of more
than one item where the sequence in which content is presented DOES NOT
affect its meaning? Would this SC be changed if that first conditional
clause were remove? Especially given that pretty much every unit has an
implicit, programmatically determinable order?}

{Greg Lowney 6/28/07: This is minor, but the wording of the final clause
("and sequential navigation of interactive components is consistent with
that sequene" makes it sound as if this clause were putting a requirement on
the navigation order, when that is actually covered in another section and
would not be appropriate here. I suggest rewriting the final clause so the
whole reads ""When the sequence in which content is presented affects its
meaning, a correct reading sequence can be programmatically determined that
is consistent with the sequential navigation of interactive components."}

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.

{Greg Lowney 6/28/07: OK. (This is now 1.3.3.)}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK. It would have been nice if diagrams could have
been incorporated into the Level AAA success criteria, but I understand not
wanting to add another criterion or making 1.4.5 more difficult to meet.}

----------------------------------------------------------
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."

{Greg Lowney 6/28/07: Close, but introducing the term "independently" in the
phrase "which can be set independently of the system volume" is problematic
because most application software only provides--and can only provide--the
ability to control its audio volume RELATIVE to the system volume. Would it
work to say "independently of or relative to 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."

{Greg Lowney 6/28/07: OK}
----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
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".

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK, it seems to be adequately discussed in the
Conformance section.}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: Thank you, but the new wording limits that which can
be stopped to purely decorative content that is "moving", which earlier in
the paragraph was clearly distinguished from that which is "blinking,
scrolling, or auto-updating". I recommend the same categories be used for
each, by changing the last sentence to read "Moving, blinking, scrolling, or
auto-updating content that is pure decoration can be stopped by the user".
Alternatively, the entire paragraph could be changed to read "Moving,
blinking, scrolling, or auto-updating content can be paused by the user, or
stopped by the user if it is pure decoration, except where it is part of an
activity where timing or movement is essential."}

----------------------------------------------------------
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."


{Greg Lowney 6/28/07: OK. I liked my suggested wording better, but this will
do.}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: The working group's new wording is better than
nothing, but I still feel it is not as broad as what we would ideally like
to see in Triple-A. Another approach would be, rather than start with a
narrow scope, start broadly and narrow the scope with exceptions such as
those you cited.  

Proposed Change:

3.3.6: For all user actions that do not terminate a process, window, or
connection, at least one of the following is true:
   1. Reversible: Actions are reversible.
   2. Confirmed: A mechanism is available for reviewing, confirming, and if
desired cancelling the action.
}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: This proposed language raises a few questions:

1. We do not currently define "markup language". Is it the intention that
this SC refer only to markup languages that are compatible with HTML and/or
XML, or is it supposed to include markup languages such as RTF that use a
completely different syntax? The difference will certainly affect the
real-world benefit of compliance, since tools will not be able to
automatically handle unusual or unfamiliar syntax. 

2. Is it required that the markup language (or schema) be publicly
documented?
}

----------------------------------------------------------
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.

{Greg Lowney 6/28/07: OK.}

----------------------------------------------------------
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."

{Greg Lowney 6/28/07: OK, but I suggest you add a better explanation of what
is meant by "before the content is encountered"; it seems like at least one
example in the Understanding document contradicts this.}

Comment 30:

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

Definition of ACRONYM is defined incorrectly as an "abbreviation made
from the initial letters", but it should be "abbreviation made from
non-contiguous letters of a name or phrase". These are usually the
initial letters, but not always; the name being abbreviated is usually
made up of more than one word, but not always; and the acronym
sometimes contains extra letters that don't occur in the original
phrase, but are added in to aid in pronunciation.

Proposed Change:

Change to "abbreviation made from non-contiguous letters of a name or
phrase".

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

We have revised the definition to read, "abbreviated form made from
the initial letters or parts of other words (in a name or phrase)
which may be pronounced as a word."

{Greg Lowney 6/28/07: OK}


----------------------------------------------------------
Comment 31:

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

Definition of ALTERNATE VERSION is defined using the term
"functionality", which should be a link to that definition.

Proposed Change:

Make the word "functionality" a link to that definition.

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

The draft has been updated as proposed.

{Greg Lowney 6/28/07: OK}


----------------------------------------------------------
Comment 32:

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

Definition of API is defined as "definitions of how communication may
take place between applications", but that should be "between
application or software components", as most API are used between
components that are not applications, and we don't want to limit our
discussion to only those API that are between one application and
another.

Proposed Change:

Change to "definitions of how communication may take place between
applications or software components".

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

Application Programming Interface (API) is now defined:
"definitions of how communication may take place between applications".

See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#apidef .

{Greg Lowney 6/28/07: No change was made to this definition. Luckily, the
term API is only used in the Conformance section and Glossary, so the error
in the definition will not deleteriously affect the standard. However, I
still recommend it be corrected. APIs are used between layers which are not
applications, such as an application using API provided by the operating
system or graphics toolkit, or a script embedded in a Web page using API
provided by the user agent. I still recommend it be changed to read "between
applications or software components".}

----------------------------------------------------------
Comment 33:

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

Definition of ASSISTIVE TECHNOLOGY is defined as "a user agent that:
1... 2 ..."; in all cases where a list of criteria is presented, it
should be made explicit whether the relationship between the elements
in the list is AND or OR.

Proposed Change:

Change "a user agent that:" to "a user agent that both:".
Change "monitoring APIs." to "monitoring APIs, and".

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

The draft has been updated as proposed.

{Greg Lowney 6/28/07: Thank you. However, I am left with two concerns. 

First, in addition to this minor change to the definition of Assistive
Technology, a separate change was made (adding the word "usually"), and the
two interact to cause a problem. The new definition is "a user agent that
both: 1) provides., and 2) USUALLY relies on services." This is is
equivalent to "Assistive Technology is a user agent that provides.and that
usually relies on services." Adding "usually" changes the second bullet item
from prescriptive to just a note. 

That alone could be addressed by changing to one of the following: 
(a) change to "a user agent that provides services., and MAY RELY on
services.", or
(b) change to "a user agent that provides services. NOTE: ASSISTIVE
TECHNOLOGY usually relies on services."

Second, since Assistive Technology is currently defined as a strict subset
of User Agents, and the definition of User Agent exclude speech recognition
used for command-and-control (as described below in comment 43), then such
speech recognition utilities are not assistive technology for purposes of
this document. That does not seem correct.

Proposed Change that addresses both concerns: 

"Assistive Technology: either:
1. a user agent that provides services., or
2. software that provides such services by relying on services. "
}

----------------------------------------------------------
Comment 34:

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

Definition of AUTHORED UNIT should be reviewed to make sure that it
agrees, at a technical level, with the committee's intention.
Currently it seems ambiguous about whether a Web unit is one type of
authored unit, or whether an authored unit must consist of more than
one Web units. Similarly, it is ambiguous about whether a subset of
the content on a Web unit (e.g. a paragraph) written by a separate
author than the surrounding content, is an authored unit. Finally, it
clearly implies that a set of Web units written by multiple authors
but intended to be used together as a set would not be an authored
unit. Are those all correct interpretations?

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

We have reformulated the success criteria and glossary to remove both
"authored unit" and "authored component" from the guidelines.

3.2.2 On Input: Changing the setting of any user interface component
does not automatically cause a change of context unless the user has
been advised of the behavior before using the component.

{Greg Lowney 6/28/07: OK. (Although see a separate comment on 3.2.2 below.)}

----------------------------------------------------------
Comment 35:

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

Definition of CONTENT currently reads ""information to be communicated
to the user by means of a user agent"" and has a Note which reads
""This includes the code and markup that define the structure,
presentation, and interaction, as well as text, images, and sounds
that convey information to the end-user."".

Content is defined as being limited to ""information"", but the
definition of ""information"" seems to exclude purely decorative
elements and elements who purpose is to create a specific sensory
experience; both of those are distinguished from informational content
in the document, but seem to clearly be part of the content. That
should be acknowledged here.

(Content also include controls whose purpose is to gather input from
the user, but I guess we don't need to call those out since they must
also have some presentation.)

Similarly, the Note seemt to say that scripts included in a Web page
are part of the content, but these don't fit into the definition of
""information"" as they might respond to user input or other triggers,
without having any presentation of their own. Thus, the Note seems to
contradict the definitions themselves.

It is unfortunate that the document defines ""information"", ""purely
decorative elements"", and content ""designed to create a specific
sensory experience"" as mutually exclusive, with no term that
currently includes them all. I believe that ""content"" should be that
term, but it would require broadening the definition of ""content""
beyond just ""information"" or broadening the definition of
""information"".

Proposed Change:

Change to "information and decorative or sensory elements to be
communicated to the user by means of a user agent, as well as code or
markup that define the stucture, presentation, and interactions
associated with those elements".

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

We have updated the definition, but have used slightly different
wording. The definition now reads, "information and sensory experience
to be communicated to the user by means of a user agent, as well as
code or markup that define the structure, presentation, and
interactions associated with those elements"

{Greg Lowney 6/28/07: Close, but once you have changed the term "sensory
elements" to "sensory experience", you should consider revising the closing
phrase, "associated with those elements". This is now the only place in the
document where the term "elements" is not used in the specific sense of HTML
elements and attributes. Change to " information and sensory experience to
be communicated to the user by means of a user agent, as well as code or
markup that define THEIR structure, presentation, and interactions"? Or just
leave as is.}

----------------------------------------------------------
Comment 36:

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

Definition of INITIALISM should make it clear that initialisms are not
pronounced as words; if they are, they would be acronyms instead of
initialisms. (At least, that's how I've heard it explained.)

Proposed Change:

Add "Note: Initialisms are generally read as strings of individual
letters rather than being pronounced as words."

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

The draft has been updated as proposed.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 37:

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

Definition of LUMINOSITY CONTRAST RATIO assumes that the foreground is
text, but one success criterion applies it to non-text content such as
diagrams.

Proposed Change:

Replaced both occurances of "text" with "foreground" in the definition.

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

We have updated the definition as proposed.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 38:

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

Definition of LUMINOSITY CONTRAST RATIO assumes that the foreground
and background are both solid colors; it is unclear how this would be
applied when that is not the case, such as when the background is a
gradient or image, or when the foreground consists of many colors. A
particularly interesting case is when the foreground is anti-aliased,
causing different pixels to be different brightness (or, in the case
of Microsoft's ClearType technology, even different colors) but all
designed to be perceived as a single brightness of a single color.

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

Thank you, the definition of contrast has been updated to address your
concerns.  The new definition text is:

contrast ratio
     (L1 + 0.05) / (L2 + 0.05), where

        * L1 is the relative luminance of the lighter of the
foreground or background colors, and
        * L2 is the relative luminance of the darker of the foreground
or background colors.

    Note 1: Contrast ratios can range from 1 to 21 (commonly written
1:1 to 21:1).
    Note 2: For dithered colors, use the average values of the colors
that are dithered (average R, average G, and average B).
    Note 3: Text can be evaluated with anti-aliasing turned off.
    Note 4: Background color is the specified color of content over
which the text is to be rendered in normal usage. If no background
color is specified, then white is assumed.
    Note 5: For text displayed over gradients and background images,
authors should ensure that sufficient contrast exists for each part of
each character in the content.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 39:

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

Definition of NATURAL LANGUAGE is "language used by humans to
communicate", but this is so broad that Fortran would be included, as
it is a way humans communicate with software.

Proposed Change:

Change to read "language used by humans to communicate with one another".

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

The guidelines now use "human language" instead of "natural language".
The definition of human language is "language that is spoken, written
or signed (visually or tactilely) by humans to communicate with one
another".

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 40:

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

Definitions of TEXT and NON-TEXT CONTENT is ambiguous about whether an
image of text is text or non-text content. Please add clarification.
This is a problem because most success criteria are written assuming
that "text" is parsable by assistive technology (i.e. not just a
picture of characters) (e.g. "text alternatives"), but others seem to
only require that "text" be readable by humans (i.e. it can be just an
image of characters) (e.g. captions on DVDs).

Proposed Change:

Add to the definition of non-text content, "Note: This includes images
of words and characters that may look like text when viewed with human
sight but are not programmatically accessible."

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

The definition of text and non-text have been changed to remove any
ambiguity that the text must be programmatically determinable (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef and
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#non-text-contentdef ).

text
    sequence of characters that can be programmatically determined,
where the sequence is expressing something in human language


non-text content
    any content that is not a sequence of characters that can be
programmatically determined or where the sequence is not expressing
something in human language

    Note: This includes ASCII Art (which is a pattern of characters)
and leetspeak (which is character substitution). .

{Greg Lowney 6/28/07: In the new definitions of text and non-text content,
please be sure to clarify somewhere that number sequences, such as the
address of a fault represented as a string of hexadecimal digits, is text
even though many would not initially consider it to be "expressing something
in human language".}

{Greg Lowney 6/28/07: In the Note for for the definition of non-text
content, please add a "an image representing text" as a third specific
example.}




----------------------------------------------------------
Comment 41:

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

Definition of PRESENTATION says "rendering of the content and
structure in a form that can be perceived by the user". This is not
technically correct, as (a) it could render just the content, not the
structure, (b) it is a form *designed* to be perceived by *a* user.
With the current definition, if the user is blind, nothing on the
display counts as presentation.

Proposed Change:

Change to read "rendering of the content and structure in a form
designed to be perceived by the user".

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

The definition has been changed to: "rendering of the content in a
form to be perceived by users".

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 42:

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

Definitions of GENEAL FLASH THRESHOLD and RED FLASH THRESHOLD each
have three criteria, the first of which is a combined area of flashes
occurring concurrently and occupying more than one quarter of any 341
x 256 pixel rectangle anywhere on the displayed screen area when the
content is viewed at 1024 x 768. Isn't that just another way of saying
one quarter of any rectangle that's 1/3 of the screen high and 1/3 of
the screen wide? Wouldn't the latter be sound less confusing and
easier to test on non-1024x768 screens?

Proposed Change:

In both GENERAL FLASH THRESHOLD and RED FLASH THRESHOLD, change list
item 1 to read "the combined area of flashes occurring concurrently
(but not necessarily contiguously) occupies more than one quarter of
any rectangular region that is one third of the screen high and one
third of the screen wide".

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

Screen size is not what determines the size of the analysis window. it
is angle of view area.  So, we have changed the provision to state
this and provided the information on what is a good estimate for
general Web content as a note.

2.3.1 Three Flashes or Threshold: Content does contain anything that
flashes more than three times in any one second period, or the flash
is below the general flash threshold and the red flash threshold.

2.3.2 Three Flashes: Content does not contain anything that flashes
more than three times in any one second period.

http://www.w3.org/TR/WCAG20/#seizure

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 43:

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

Definitions of GENEAL FLASH THRESHOLD and RED FLASH THRESHOLD, it
might be worth noting, will eventually need to be revised when OLED
technology allows for increasing use of very large, animated displays.
Picture one big OLED display replacing the sign board in the lobby of
a major office building, listing all the businesses and their
locations; in this case the user will be focusing their attention on
one small area of the large sign, but close enough to read the text
easily. In that case, the entire area the user is looking at might be
flashing, but it still would not be 1/3 of the screen high and 1/3 of
the screen wide.)

Proposed Change:

In both GENERAL FLASH THRESHOLD and RED FLASH THRESHOLD, append to
list item 1, "or designed to occupy a region larger than 6" by 6" on
the intended physical display".

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

Screen size is not what determines the size of the analysis window. It
is angle of view area. So, we have changed the provision to state this
and provided the information on what is a good estimate for general
web content as a note.

If the author KNOWS that a larger screen or viewing distance will be
used (for example a very large display in a lobby) then they can
calculate the size of the area in pixels that they should analyze.

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 44:

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

Definition of SPECIFIC SENSORY EXPERIENCE could use an example to help
readers understand it. I find it hard to come up with an example that
one couldn't argue also performs a function, even if that function is
creating a specific sensory experience.

Proposed Change:

Add "Example: A Web site advertising a horror-themed game plays subtly
disturbing music in order to make the user feel a sense of immersion
in the theme." (However, one could argue that such music "performs a
function" in this case.)

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

The following has been added to the definition.
"Examples include a performance of a flute solo, works of visual art etc. "

{Greg Lowney 6/28/07: OK}

----------------------------------------------------------
Comment 45:

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

Definition of USER AGENT is "any software that retrieves and renders
Web content for users". In several places it is emphasized that this
includes assistive technology, but this definition seems to exclude
many types of assistive technology such as speech recognition used for
command-and-control, which neither retrieves nor renders, but does
rely on access to the information being rendered. Also, the word
"retrieves" seems to imply fetching from some remote source (e.g. over
the Web), which would exclude screen readers; on the other hand,
"retrieves" could be taken to mean getting the data from anywhere,
including from another user agent, but by that interpretation a
display driver would count as assistive technology.

Proposed Change:

Change to read "any software that retrieves and renders Web content
for users, or manipulates such content to assist the user in using the
Web content or controls"

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

The current wording is taken from UAAG and the proposed wording is not
sufficiently different to warrant changing the UAAG definition. Most
of what was added could be interpreted as part of rendering the
content.

{Greg Lowney 6/28/07: The response from the working group did not address my
concern. If Assistive Technology is defined as a subset of User Agents, and
User Agents exclude speech recognition used for command-and-control, then
you are saying Dragon NaturallySpeaking is not assistive technology for
purposes of this document. That does not seem correct. However, I do think
that it would be better addressed by changing the definition of assistive
technology, and leaving the definition of user agent as it stands.}

=====================================================================

{Greg Lowney 6/28/07: New comments begin here...}

New Comments on Draft 17 May 2007

1.	The Conformance section does not address the question of which
platforms need to be supported. If something only runs on one platform, what
determines if it is accessible? What if the plug-in required for viewing it
does not support Linux? 

2.	Conformance, Optional components of a conformance claim, uses the
term "machine-readable metadata", which occurs nowhere else in the document.
Is the intention that this metadata be in a standardized form, or merely
that it can be accessed as text without the use of optical character
recognition? Should it be added to the glossary?

3.	2.2.4 has the title "Timing:" which is also the title of 2.1.1. In
all other cases, each title is unique. I suggest changing the title of 2.2.4
to "Timing (Enhanced):"

4.	I recommend Examples of Conformance Claims in the Understanding
document include references to more than one screen reader. Currently, Jaws
is the only one named, and it is named five times. 

5.	I believe I understand the rationale for moving several (former)
success criteria into the Conformance section, but I am worried about two
things. First, they are no longer easily referenced; can you call them
something like "CR6.1, No Keyboard Trap"? Second, it seems like they are
likely to be overlooked when someone is reading what they consider to be the
key sections, or a summary of the guidelines. I would not be surprised to
see the H1 section titled "WCAG 2.0 Guidelines" being extracted or
considered the key portion, and it used to be so, but now the H2 section
titled "Conformance Requirements" is just as important for actual content
developers, not just managers. Some specific factors that could lead the
latter to be overlooked are (a) it's only H2 instead of H1, (b) it is
surrounded by other H2 sections that look much less like lists of guidelines
and more like paragraphs of text, and (c) the sections around it are more
applicable to managers than to individual designers and authors. I don't
have a good suggestion for mitigating this problem, but perhaps the working
group can think of something.

6.	3.2.2 "On Input: Changing the setting of any user interface
component does not automatically cause a change of context unless the user
has been advised of the behavior before using the component." None of the
Understanding or Techniques addresses the common situation where several
form fields are used to enter the fixed-length segments of multi-part value,
such as a serial, phone, or social security number. In those cases it is
common for the focus to automatically move to the next field when the
correct number of characters have been entered. While this is common and a
convenience to many users, it would violate this success criterion and
should be addressed specifically.

7.	1.1.1 bullet 1, "Controls-Media", could be renamed to "Controls,
Input" to be more consistent with the other bullets (e.g. "Media, Test,
Sensory" and "Decoration, Formatting, Invisible".

8.	1.3.3. Minor, editorial only, but you might consider changing the
either the title ("Size, Shape, Location") or the text ("shape, size, visual
location, or orientation") so the two use the same order.

9.	1.4.5 Contrast (Enhanced) says "Text.have a contrast ratio of at
least 7:1. Large-scale text.can have a contrast ratio of 5:1". The second
clause should read "can have a contrast ratio of AT LEAST 5:1."

10.	I consider it unfortunate that the Keyboard section does not contain
a AA or AAA criterion addressing the benefit of having a keyboard interface
that does not require reference to spatial arrangement of items on the
visual display. For example, "Non-relative: All functionality of the content
is operable through a keyboard interface without requiring timings for
individual keystrokes or reference to the spatial arrangement of content or
controls on the visual display."

11.	2.4.4 Link Purpose (Context): I don't consider this a Single-A
criterion, as this level of information is often not available to most
users. I think that in the vast majority of cases, it is merely implied
rather than in any way made explicit. I would be fine with it being demoted
to either Double-A or Triple-A.

12.	2.4.4 Link Purpose (Context): Note that in addition to link text and
"programmatically determined link context" the Title attribute is often used
to provide information about the purpose of a link. This is done in the WCAG
2.0 document itself, where the title attribute of link to a definition is
prefixed with "definition: ", and many user agents provide a UI to present
this title to the user.

13.	2.4.4 and Definition of "programmatically determined link context",
I believe this would more properly be described as "programmatically
DETERMINABLE link context", as the current wording literally means link text
that is assigned programmatically.

14.	2.4.8 Link Purpose (Link Text): Note that I don't think even the
WCAG document itself meets this criterion.

15.	3.2.1 On Focus: This prevents an unexpected "change of context" when
any component receives focus, but no criterion currently restricts
components from making other persistent changes, such as changing the state
of a check box, simply because it received focus. This would be analogous to
the case of a radio button becoming selected merely because the user moved
focus to it, an error which we have seen in some desktop applications. I
would have liked to see added "....or any effect that will persist after the
component has lost focus". If this cannot be added to Single-A at this
point, could it be added as Double-A or Triple-A?

New comments on the Understanding document

16.	"Content that is not accessibility-supported contains a link to
information about how to move focus back to the accessibility-supported
content via the keyboard." This fails to address the part of the Conformance
Requirement that says "the method for doing so is described BEFORE the
content is encountered".

	Thanks,
	Greg