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

Comment 10:

Source: http://www.w3.org/mid/20060505012957.4E420BDA7@w3c4.w3.org
(Issue ID: LC-489)

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

Terminology used in related technical specifications should be
consistent, unless there are compelling reasons to the contrary. There
are no strong reasons why basic terminology in WCAG 2.0 should differ
from ATAG, UAAG and indeed WCAG 1.0.

Proposed Change:

Change "principles", "guidelines" and "success criteria",
respectively, to "guidelines", "checkpoints" and "provisions"
throughout WCAG 2.0 and supporting documentation.

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

The elements in WCAG 2.0 differ from those in the other documents.
Using the same terms would be misleading.  For example what you
suggest we list as checkpoints are guidelines in this document. The
success criteria would be the closest thing to checkpoints but they
would be under checkpoints with the labeling you propose, so the
things you must check off would not be the checkpoints but what was
under them.  Also, we have a checklist that is success criteria.  To
label the guidelines as checkpoints but have different things be in
the checklist would be confusing.

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

Source: http://www.w3.org/mid/20060505020015.BC90BBDA7@w3c4.w3.org
(Issue ID: LC-490)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

The expression "conveyed through presentation" is not defined, and
therefore open to divergent interpretations. If, for example, an
implementor decided that "presentation" could be construed as meaning
"auditory presentation provided by a speech-enabled user agent", and
it turned out that very few aspects of the structure of the content
were conveyed in an auditory presentation, then it could be concluded,
contrary to the purpose of the guidelines, that almost none of the
structure need be programmatically determinable. I can think of two
alternative ways in which the concept of "conveyed through
presentation" could be more precisely defined.

1. Any aspect of the information or structure that is evident from the
presentation of the content, in any modality, must be able to be
programmatically determined.

2. Any aspect of the information or structure for which the author
provides presentational hints to the user agent, must be able to be
programmatically determined. Presentational hints may include style
parameters, visual formatting (layout, font changes, etc.), audio
formatting (parameters to control a speech synthesizer) and other
aspects of the content designed to influence its presentation in one
or more sensory modalities. I think the second proposal is the more
practicable solution as it doesn't leave authors wondering what might
be apparent in a presentational context with which they are
unfamiliar, that needs to be made programmatically determinable.

Proposed Change:

Rewrite the success criterion, add a note to it, or rewrite the
definition of "presentation" to clarify the requirement in accordance
with the problem raised and the solutions suggested above, or indeed
any other solution that addresses the lack of clarity in the current
text.

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

We have updated the definition of "presentation" to "rendering of the
content in a form to be perceived by users." We have also added a
definition for "relationships."

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

Source: http://www.w3.org/mid/20060505022059.A9CC3BDA7@w3c4.w3.org
(Issue ID: LC-491)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This criterion is specific to aspects of visual presentation. Suppose
however that the content is written in VoiceXML or a comparable format
designed to control auditory presentation. Surely the same requirement
should apply, for the benefit for example of users who are deaf.

Proposed Change:

Generalize this criterion so that it is not modality-specific, i.e.,
not limited to visual presentation.

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

SC 1.3.3 (formerly 1.3.5) is intended to address issues where the
ability to understand and operate content depends on the 2-dimensional
spatial presentation which is only an issue for blind and
visually-impaired users. We can reconsider if a specific example is
provided that would be an issue for deaf users.

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

Source: http://www.w3.org/mid/20060505030913.0CB37BDA7@w3c4.w3.org
(Issue ID: LC-493)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Blinking is not a "time limit" on reading or interaction. Therefore,
sc 2.2.2 does not belong under this guideline.

Proposed Change:

Move 2.2.2 to guideline 2.3, generalizing the wording of guideline 2.3
if necessary. Alternatively, move this criterion to its own guideline
if photosensitivity is not the main rationale and if you don't want to
expand guideline 2.3 to cover the issues addressed by this criterion.

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

Blinking does not fall within the frequency range that causes seizures
and is therefore not appropriate under guideline 2.3. That's why the
working group added the note referring to guideline 2.3 to this
success criteria. Blinking is a timeout issue though if users are
unable to read blinking text or images of text or to comprehend
blinking images before they change.

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

Source: http://www.w3.org/mid/20060505042559.74FA9BDA7@w3c4.w3.org
(Issue ID: LC-494)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Sc 2.3.1 refers to "content", but sc 2.3.2 refers instead to "Web
units". Since any content conforming to the guidelines consists of one
or more Web units, the word "content" should refer to all Web units
within the scope of the conformance.

The main point here is this: terminology should be consistently used.
If there is a technical distinction to be drawn between "content"
(2.3.1) and "Web units" (2.3.2), it needs to be explained, or better,
expressed directly in the text of the criteria.

Proposed Change:

Change "Web units do not contain any components that flash" to
"Content does not flash", or "The content does not flash".

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

Thanks. We changed 2.3.2  from    "Web units do not contain any
components that…" to  "Content does not contain anything that
flashes…"

----------------------------------------------------------
Comment 15:

Source: http://www.w3.org/mid/20060505042926.2AAB3BDA7@w3c4.w3.org
(Issue ID: LC-495)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Should the sentence begin with "Content" or with "The content" (i.e.,
the content subject to WCAG 2.0 conformance)?

Proposed Change:

Change "Content" to "The content" if appropriate, making sure that it
is consistent with wording used elsewhere (i.e., make the change
consistently).

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

When the word "the" is used before a word it means that the writer is
referring to the instance of this word that occurred previously.  If
we begin a success criterion with "the content" it would mean that we
were referring to the the content in the previous sentence.   This is
not always true. In fact, in different places, there is a different
use of the word content that preceeds it.  Therefore "the content" is
used before content only if the word content has already been
introduced in the same sentence (or paragraph).

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

Source: http://www.w3.org/mid/20060505043825.29200BDA7@w3c4.w3.org
(Issue ID: LC-496)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Are there "processes" which are not "tasks" for purposes of this
criterion? I can't think of anything that would qualify. If I perform
an interaction in a user interface, surely I am performing, or
undertaking, a task and the result of my doing so will be the result
of the task performed. If this is right, then make the change proposed
below.

Proposed Change:

Change "process or task" to "task" or "task performed by the user".

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

We agree that WCAG should be consistent in our use of terms. However,
we think that "process" is more appropriate than "task" in this case.

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

Source: http://www.w3.org/mid/20060505045244.3A3B1BDA7@w3c4.w3.org
(Issue ID: LC-497)

Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):

How does 2.4.8 differ from 2.4.4? How can the purpose of a link be
programmatically determined?

Proposed Change:

Rewrite this sc to clarify what is required and how it differs from
2.4.4, or rewrite 2.4.4 to cover the same issues, or delete 2.4.8.

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

We have changed SC 2.4.4 to make it clearer that it may be necessary
for the user to request context information to understand the purpose
of the link at level A. At level AAA, the purpose of the link can be
understood from the link independent of its context. We have also
changed the language to clarify that the text describing the purpose,
and not the purpose itself, is what can be programmatically determined


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

Source: http://www.w3.org/mid/20060505050037.8F652BDA7@w3c4.w3.org
(Issue ID: LC-498)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Under item 2, consider using "task" rather than "process", especially
if my comment on "tasks and processes" is accepted. It is important to
use the same word for the same purpose consistently throughout the
document.

Proposed Change:

"next step in the task" rather than "in the process".

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

The working group agrees that WCAG should be consistent in our use of
terms. However, we think that "process" is more appropriate than
"task" in this case.

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

Source: http://www.w3.org/mid/20060505050641.36CADBDA7@w3c4.w3.org
(Issue ID: LC-499)

Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):

Should "context-sensitive help" be defined in terms of "the task, or
the step in the task, currently being performed"? This would require
it to be specific to the over-all task while allowing individual steps
in a task to have their own help items.

If it is better to think in terms of tasks, maybe context-sensitive
help should be defined accordingly.

Proposed Change:

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

The current wording of the definition of "context-sensitive help"
neither requires nor prohibits the suggestion here. We think it is
better for designers to have the flexibility to determine the most
appropriate context-sensitive help for their application.

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

Source: http://www.w3.org/mid/20060505051331.554A2BDA7@w3c4.w3.org
(Issue ID: LC-500)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Principle 3 refers to "controls" ("content and controls"). Are
"controls" the same as "user interface components within the content"
mentioned in guideline 2? I think they are, or should be, the same and
accordingly that the same terminology should be used.

Proposed Change:

Change "content and controls" in Principle 3 to "content and user
interface components" or, perhaps better, "content (including any user
interface components it contains)".

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

We are trying to avoid parentheticals in the princples so Principle 3
has been updated to read, "Principle 3: Understandable - Information
and operation of user interface must be understandable by the user. "

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

Source: http://www.w3.org/mid/20060505052609.63E39BDA7@w3c4.w3.org
(Issue ID: LC-501)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

The content (i.e., everything within the scope of conformance), can
and in many instances will consist of multiple Web units.

Proposed Change:

Change "the Web unit" to "every Web unit", or "every Web unit within
the content".

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

Success Criterion 3.1.1 has been changed to read, "The default human
language of each Web page within the content can be programmatically
determined."

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

Source: http://www.w3.org/mid/20060505052945.E9C9FDAE86@w3c4-bis.w3.org
(Issue ID: LC-502)

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

The same as 3.1.1.

Proposed Change:

Change "the Web unit" to "Every Web unit" (or whatever language is
chosen to clarify this).

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

"Web unit" is not needed here because the requirement applies to any
type of content for which a claim would be made. Success Criterion
3.1.2 has been revised to read, "The human language of each passage or
phrase in the content can be programmatically determined."

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

Source: http://www.w3.org/mid/20060505054045.EB029BDA7@w3c4.w3.org
(Issue ID: LC-503)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This criterion is unnecessarily and arbitrarily restricted to form
controls and fields (of forms). This restriction is undesirable.

Proposed Change:

Rewrite the sc in terms of user interface components rather than forms
and fields. For example, it could be expressed in terms of changing or
setting the state of a user interface component, where state would be
defined to include any kind of value that the component can accept as
input. Of course, there are other, simpler ways of generalizing this
to user interface components.

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

We agree, and have updated the wording of SC 3.2.2 (formerly 3.2.3).
It now reads, "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.  "

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

Source: http://www.w3.org/mid/20060505054555.EC948BDA7@w3c4.w3.org
(Issue ID: LC-504)

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

The mention of "tab order" is somewhat technology-specific and should
be generalized in terms of changes of focus.

Proposed Change:

Rewrite the exception about tab order in terms of a change of focus to
the next component in a sequence, or in other language that is
suitably general.

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

We have removed the mention of tab order from SC 3.2.2, so your
proposal has been overtaken by events and is no longer applicable.

Received on Thursday, 17 May 2007 23:36:33 UTC