- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:27:01 -0700
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: public-comments-WCAG20@w3.org
Comment 11:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-971)
Having the HTML spec say that @alt was to contain a short description
of the image caused years of dysfunctional ALT texts to be written.
Haven't we had enough of this? "Descriptive" is narrow in a
misleading way; need something that is more evocative of the breadth
of information covered by these various components and their short
labels.
Proposed Change:
Use "are explanatory" or "are fitting."
----------------------------
Response from Working Group:
----------------------------
While we agree that "descriptive" can be misinterpreted, we have not
been able to come up with a better adjective to convey what is sought.
We think that "explanatory" or "fitting" will be less clear to readers
who do not already understand the issues.
----------------------------------------------------------
Comment 12:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-972)
If there is a mechanism that satisfies one of these, there is a
mechanism that satisfies the other, because the UA can infer meaning
from pronunciation and vice versa.
Proposed Change:
merge these two clauses
----------------------------
Response from Working Group:
----------------------------
There are many examples where knowledge of pronunciation are not
sufficient to provide meaning. For Japanese, meaning issues are not
always the same as pronunciation issues. The meaning is needed for
words or phrases which are unfamiliar to the users even if user knows
the pronunciation/reading. And the pronunciation is needed for Han
characters, especially for proper nouns such as the name of a person
or a place. There are also unfamiliar Han characters which are
difficult for users to read. Additionally, Japanese screen readers
can't read some Han characters correctly in some cases as the Han
characters have multiple readings in general.
----------------------------------------------------------
Comment 13:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-973)
Principle is "First, Do no Harm." Compare with Hippocratic Oath. This
is a safety requirement, it comes before access requirements, and is
not an access requirement.
Proposed Change:
Introduce separate principle for safety and move this guideline to it.
Make it the first, before others. Remove all obstacles to
implementing this provision severable from the rest.
----------------------------
Response from Working Group:
----------------------------
This does not change conformance to the guidelines any and therefore
has no actual impact on Web content. There is no suggestion for any
other success criteria under this principle. It does not seem like a
sufficient justification to create a whole new principle with one
guideline with 2 success criteria. We have decided to keep this under
Ability to Operate section for practical and logistical reasons.
----------------------------------------------------------
Comment 14:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-974)
Navigation is a User Agent function enabled by structure in the
content. This is not a content guideline, but a user experience
requirement handled in the User Agent.
Proposed Change:
Replace with a narrower provision that says "navigation paths defined
in the content encoding correspond to the logical order information
which is the subject of 1.3.3"
----------------------------
Response from Working Group:
----------------------------
Thank you for bringing this to our attention. We have added the
following definition for the term "sequentially navigated":
navigated sequentially
navigated in the order defined for advancing focus from one element
to the next with the keyboard.
We have also added the following explanation to the Intent Section of SC 2.4.6:
The way that sequential navigation order is determined in Web content
is defined by the technology of the content. For example, simple HTML
defines sequential navigation via the notion of tabbing order. Dynamic
HTML may modify the navigation sequence using scripting along with the
addition of a tabindex attribute to allow focus to additional
elements. In this case, the navigation should follow relationships and
sequences in the content. If no scripting or tabindex attributes are
used, the navigation order is the order that components appear in the
content stream. (See HTML 4.01 Specification, section 17.11, "Giving
focus to an element").
----------------------------------------------------------
Comment 15:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-976)
On the face of this, the requirement is unenforceably vague. Need to
spell out what you mean by "the purpose of the link" and limit the
requirement to concepts the user is likely to recognize.
Proposed Change:
Re-state as (roughly) "When the result of activating a link falls
within the general meaning of a widely used and understood term or
notion such as 'help' or 'home,' and there is a widely-reognized name
or URI for this concept, the association of this link with that
concept is machine-recoverable from the encoding of the content (Note
'encoding').
----------------------------
Response from Working Group:
----------------------------
While "purpose" may not perfectly communicate the goal of the link
description, it was the best term the working group could come up
with. The working group does not feel that using the longer and more
technical description that you proposed will help readers understand
the success criterion.
----------------------------------------------------------
Comment 16:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-977)
This is a general usability practice.
Proposed Change:
Reorganize to address overlap with general usability in a positive way.
See other comments on organization and explanation.
----------------------------
Response from Working Group:
----------------------------
There is some overlap with general usability, but we are staying away
from usability as any organizational principle due to strong feelings
that WCAG should not address general usability issues that do not
affect people with disabilities disproportionately.
----------------------------------------------------------
Comment 17:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-978)
unenforceably vague
Proposed Change:
"item which system feels to be in error is identified."
----------------------------
Response from Working Group:
----------------------------
Thank you for your comment. We have revised SC 3.3.1 (formerly 2.5.1)
as follows:
If an input error is automatically detected, the item that is in error
is identified and described to the user in text.
----------------------------------------------------------
Comment 18:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-979)
Identifying the bad entry is enough so long as the entry is
prompted/labeled adequately. In other words affordance of help
recovering from data entry errors is good advice, but too demanding at
a Level 1 success criterion standard.
Also, authors just get this wrong too easily. How many times does the
text explanation say "bad password" when the error was in the
username?
Error explantions should follow the culture of the desktop. If there
is a screen reader in use, this is the screen reader's habits for
expressing error messages. The content should define the error as
formally as they can. Let the UA and AT worry the friendly message.
If the UA knows it is a type error and the type is identified, then
that is enough to synthesize an error explanation in diction the user
will understand in the culture of their desktop formed by their AT.
System codes would not make that error. The point is that the server
refused the authentication information pair of username *and*
password.
Proposed Change:
Separate identification of the bad data from explanation of how it is
bad. Move explanation of nature of error to lower level. Allow
satisfaction by either text message or metadata understandable by
user's automation.
----------------------------
Response from Working Group:
----------------------------
As per your suggestions, in the Understanding document we have added
that the error should be specific as possible.
The working group does not think we should move the explanation of the
nature of the error to a lower level. As a small matter of
distinction, the success criterion does not require an explanation. It
requires that the error is described to the user, that she be able to
understand it. An explanation is a detailed description. The success
criterion is not requiring a detailed description, but simply a
description of the error, which is not as rigorous as an explanation
of the error.
The intent section says:
"The intent of this success criterion is to ensure that users are
aware that an error has occurred and can determine what is wrong."
The working group believes it is reasonable to require a description
of the error at Level A, such as "error: use only numbers" for a
telephone field that was filled with letters, rather than "an error
has occurred" which could be confusing. A description will be
necessary at Level A for many people with disabilities, including
those with cognitive disabilities.
This success criterion does not prevent the use of programmatic
information which can be used by assistive technology or the user
agent to identify and provide error information. There must be some
mechanism to provide the error information to the user with all
technologies in use today and the requirement for text guarantees
that. Even when provided by the assistive technology or user agent
rather than the content author, the information can still be conveyed
in some form of text to meet this requirement. Thus, we don't see the
requirement for text as being too restrictive.
----------------------------------------------------------
Comment 19:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-981)
Navigating to another frame or page is "when an element receives
focus" and is at the same time a change of context. There is an
anticipated change of context in navigation acts which cause an
element to receive focus. [AT can track the focus.] What you want to
eliminate is surprises -- context changes that could not be predicted
from the prior context in which the focus change was precipitated. So
you need language that distinguishes the surprises to be avoided from
the context changes that the user will anticipate.
Proposed Change:
Re-state as (roughly) "When and element receives focus, it does not
have any side effects in the form of a further change of context."
----------------------------
Response from Working Group:
----------------------------
We have reworded the success criterion to eliminate any ambiguity that
the receiving of focus is the change of context that is not
permitted. The success criterion now reads:
"SC 3.2.1 When any component receives focus, it does not initiate a
change of context."
----------------------------------------------------------
Comment 20:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-982)
The definition in the Glossary makes the similarity test for things
that are to be identified alike too narrow. It says identical result;
that is much too narrow. This equivalence class should be made as
broad as possible until it starts to degrade the user's ability to
predict the system response from the prompt material. For example,
context-sensitive help will be identified in the context menu simply
as 'help' although the precise results are different for each context.
This minimizes the vocabulary the user has to learn. The class of
like-identified action opportunities defines the actual concept; the
question is how the user's interpretation of the prompt material --
the concept identification -- matches this.
Proposed Change:
Move to section under the education and usability principle
"repetition builds recall". In other words, address usability
explicitly in the development of the set of provisons, don't just make
a vague disclaimer that doesn't admit how what we do say is straight
from usability, but applied to mitigating PWD risks of funtion
failure, task failure or interminable task times.
----------------------------
Response from Working Group:
----------------------------
We have revised the introduction text to read, "The guidelines do not
include standard usability recommendations except where they have a
significantly greater impact on people with disabilities than on other
people." We have also changed "identical" to "same" in the definition
of "same functionality".
Beyond this, we are not using usability as an organizing principle and
are not addressing usability explicitly.
----------------------------------------------------------
Comment 21:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-983)
Without some restriction on what set is meant, this success criterion
is meaningless. But for what you want to say, it can be fixed.
Proposed Change:
"the Web units comprising the scope of a conformance claim"
----------------------------
Response from Working Group:
----------------------------
We have revised this success criterion to reference a "set of Web
pages" and have included a definition for that term.
----------------------------------------------------------
Comment 22:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-984)
This is a general usability matter; while doing well on this helps
PWD, it is not clear that it meets your claimed requirement for
inclusion that there be a markedly disproportionate effect on the
experience of the PWD user.
Proposed Change:
Re-state filter criterion for practices in terms of "do cover
usability enhancements that are readily achievable and make major
contributions to mitigating PWD hazards in the browse experience. But
generally good usability practices that have a generally comparable
benefit for PWD and TAB users are not covered here." I.e. lead with
positive because navigation, view controls, and labeling/prompting are
general usability strategies and are of the essence in securing a Web
that works for PWD.
----------------------------
Response from Working Group:
----------------------------
Thank you for your comment. We have adopted your proposed wording in
the Introduction.
SC 3.2.4 explicitly outlines benefits to people with disabilities in
the "Intent of this success criterion" section of How To Meet SC
3.2.4. The intent of this success criterion is to ensure consistent
identification of functional components that appear repeatedly within
a set of Web pages. A strategy that people who use screen readers use
when operating a Web site is to rely heavily on their familiarity with
functions that may appear on different Web pages. If identical
functions have different labels on different Web pages, the site will
be considerably more difficult to use. It may also be confusing and
increase the cognitive load for people with cognitive limitations.
Therefore, consistent labeling will help.
----------------------------------------------------------
Comment 23:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1192)
This clause is unenforceably vague. NLP looks at the term in context
and can always produce a vector of meanings weighted with
probabilities. This language gives no standard as to how well one has
to have isolated one meaning before considering "meaning can be
determined without [further help e.g.] pronunciation." Are you OK if
the right meaning is the maximum-likelihood estimate? If it is more
than 80% likely? If no other meaning is as close as half as likely?
What?
Proposed Change:
merge into 3.1.3, as the relevant mechanisms are interchangeable.
----------------------------
Response from Working Group:
----------------------------
SC 3.1.3 and SC 3.1.6 apply to different sets of words. SC 3.1.3
applies only to words used in an unusual or restricted way, while SC
3.1.6 applies to any words where information about pronunciation is
needed.
We have revised SC 3.1.6 to read, "3.1.6 Pronunciation: A mechanism is
available for identifying specific pronunciation of words where
meaning is ambiguous without knowing the pronunciation."
Chinese has a number of common characters that have more than one
pronunciation in Mandarin Chinese; sometimes the meaning is the same,
but sometimes it is not. Dutch also has homographs; sometimes the only
difference is words stress (examples at
http://nl.wikipedia.org/wiki/Homograaf). For Japanese, there may be no
need to specify the meaning of a name written using Han characters,
but there may be a need to provide the pronunciation.
While the same mechanism may be used to satisfy both SC 3.1.3 and SC
3.1.6, weaker mechanisms may suffice. There are sufficient techniques
for SC 3.1.6 that would not be sufficient for SC 3.1.3, e.g.,
providing the pronunciation immediately following the word.
----------------------------------------------------------
Comment 24:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1193)
Clause is trivially vague. It will either be satisfied or
inapplicable, because there is no standard for what set of Web units
is pertinent.
Proposed Change:
Introduce concepts of breadcrumb trail as vertical thread through
topic categories from here to home and task-phase bar as steps in a
sequential process. If one is in a sequential process, need latter to
get credit; else former. Because of former, never 'not applicable.'
Location within site is always applicable and desirable.
----------------------------
Response from Working Group:
----------------------------
We have revised the success criterion and have added a definition to
the glossary for "set of Web pages." We have also modified the
description of G128: "Indicating current location within navigation
bars" to clarify that this technique is particularly appropriate for
sequential tasks.
----------------------------------------------------------
Comment 25:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1194)
These provisions belong under principle 3. Their domain is the
understanding of action opportunities, not whether or not the user can
activate them.
Proposed Change:
Reorganize. See comments elsewhere on organization.
----------------------------
Response from Working Group:
----------------------------
We have moved moved Guideline 2.5 to Principle 3. It is now Guideline 3.3.
----------------------------------------------------------
Comment 26:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1195)
Clause is trivially vague. It will either be satisfied or be
inapplicable, because there is no objective standard for when the
"and..." condition is met.
This provision is general good usability practice.
The suggestions usually come from the browser's memory of user's
response to similar questions in other content. Hence is not a
content requirement, but a user experience desideratum which may be
satisfied by user's automation or the data received from the author's
automation.
Proposed Change:
move to informative annex noting good usability practices that are
especially appreciated in the PWD Web experience.
----------------------------
Response from Working Group:
----------------------------
We do not agree that the clause is trivially vague. We agree that this
provision is good general usability practice, however, we feel that
this is an accessibility issue because of its disproportionate impact
on users who have cognitive disabilities that impair problem solving.
----------------------------------------------------------
Comment 27:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1196)
Sub-case 1 is by definition not applicable. If the action is
reversable, then the user action does not cause i.e. commit to the
transaction.
Sub-case 2 is insufficient. Having the system check for a subset of
the system's concerns is in no way an indication of the user's
informed consent to commit the transaction.
Sub-case 3 is the requirement.
Proposed Change:
Eliminate OR and leave the "opportunity to review" provision only.
Make a note that if the transaction is reversible then the review is
required before the subsequent commit transaction, but that this test
is not required at the interim step.
----------------------------
Response from Working Group:
----------------------------
To address your concern with the first bullet we have updated it to
require that transactions are reversible rather than actions. The
working group believes that the second bullet is important for
complicated transactions where it might not be appropriate to review
all data in the final step and thus has retained that option. We have
updated the wording of the second bullet. 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.
We have revised the list in this section as follows:
1. Transactions are reversible.
2. Submitted data is checked for input errors before going on to
the next step in the process.
3. A mechanism is available for reviewing, confirming, and
correcting information before finalizing the transaction.
----------------------------------------------------------
Comment 28:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1197)
is too narrow
Proposed Change:
"for any input where the possible inputs are more varied than five to
nine well-known choices"
----------------------------
Response from Working Group:
----------------------------
We have revised this success criterion to read, "3.3.5 Help:
Context-sensitive help is available." However, the group felt that
help could be needed and should be provided for a wider range of
choices than just "greater than five."
----------------------------------------------------------
Comment 29:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1198)
Distinguish requirements that apply at the User Interface, i.e. in the
Rendered Content, from requirements that apply at the network
interface, i.e. in the Communicated Content.
The latter is defined by how the content is represented as it passes
from the author and server's automation to the user's automation.
We may be able to resurrect the notion of a [generic] document object
model as a slightly stronger statement of the 4.1 'clean parse'
language and tie "programmatically determined" clauses there.
Proposed Change:
Distinguish requirements that apply at the User Interface, i.e. in the
Rendered Content, from requirements that apply at the network
interface, i.e. in the Communicated Content.
1.3.2 is an example of the former.
1.3.2 is an example of the latter.
----------------------------
Response from Working Group:
----------------------------
This difference is too subtle and the current organization would be
more salient to most users of the guidelines.
----------------------------------------------------------
Comment 30:
Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1199)
The role of User Agents is underdeveloped in this document, and the
effectiveness of the document suffers.
There is a whole missing principle of "different strokes for different folks."
It is not enough to say "people have to perceive the presentation of
information." The encoding or representation of the information in
that rendered view must be recognizable. The success criterion is in
terms of cognition, not perception.
Further, there is no "one size fits all" presentation that affords a
functional user experience for all people. So the fundamental
requirement is one of personalization: that the same information can
be presented and accepted in diversified look-and-feel variants to
reach all the people.
The User Agent doesn't just render the display and process user input
events. It also affords the user view-management funtions such as
navigation within the document and presentation property profiling.
These are managed between the user and the user agent. Sometimes it
is not easy to make the rendering transform plastic enough to enable
use by all users, and the server has to offer content choices to
achieve the full range of under which the web content and/or service
is available.
Proposed Change:
Clearly represent that the guidelines set out in this document apply
to the data passing through the network interface, not the signals
passing through the user interface.
Explain the requirements here (in this document, not a companion note)
starting with User Interface requirement, but transformed by the
capabilities and needs of User Agents.
----------------------------
Response from Working Group:
----------------------------
The 'Components of Web Accessibility' section of the introduction now contains:
It is important to note that Web content is just one aspect of
accessibility. Just as important as accessible Web content is the
availability of accessible browsers (and other user agents) that can
adapt and present the content in the best form for the user.
Accessible Web technologies and accessible tools for creating Web
content are also important. For an overview of the different
components of accessibility and how they work together see:
* Essential Components of Web Accessibility - Explains how the Web
Content Accessibility Guidelines work with the other WAI guidelines
and with assistive technologies to provide access to the Web by people
with disabilities.
* User Agent Accessibility Guidelines (UAAG) Overview - Introduces
guidelines on the design of accessible Browsers and other user agents.
* Authoring Tool Accessibility Guidelines (ATAG) Overview -
Introduces guidelines on the design of authoring and evaluation tools.
Received on Thursday, 17 May 2007 23:27:34 UTC