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

Comment 31:

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1200)

"content is perceivable" is an oxymoron.  The two are not comparable.
The rendering is perceivable.  In the rendering, the content must be
recognizable.

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

Principles are not a technical provisions, but something to provide a
gestalt. We have changed them to a certain extent but we want them to
be short slogans that are easily remembered and understood as
overarching principles.

They now read:

1. Perceivable - Information and user interface must be perceivable by the user.

2. Operable - User interface components must be operable by the user.

3. Understandable - Information and operation of user interface must
be understandable by the user.

4. Robust - Content must be robust enough that it can be interpreted
reliably by a wide variety of user agents, including assistive
technologies.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1201)

It doesn't work until the content is re-united with an adapted presentation.

Proposed Change:

change to:
Ensure that presentation can be adapted while preserving content.

Alternate language:
Enable personalization of presentation.

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

Guideline 1.3 has been reworded to reflect adaptation of presentation.
Separation of content and presentation would be a technique for this.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1202)

Requiring that the other way of showing the color-signaled information
is visual is a UI requirement.  It is not a content requirement.

This requirement is inappropriate for a claim that includes SALT in
its baseline such that the default presentation would speak the
information as well as show it with color.

Compare with UAAG 2.3.  Sometimes you should not try to replicate the
richness of the color coding in other, more limited property spaces,
but rather signal that there is further information and expand on the
further information on user interactive request.

Compare also to the 'minimized' treatment of notes in a DAISY player.
Here the presence of a note is evident, the content of the note is
available but on an 'ask for' basis.

24 bits per pixel of color-coded information is just too much
information to assume that other visual effects can capture it all.

Proposed Change:

User Interface requirement:

strike the word 'visually' to leave "is also evident, or is available
and the availability of more information is evident"

Content requirement:
The default prsentation afforded without user intervention satisfies
the above requirement.

[alternate language:  .. is visually evident ... in the
author-designed visual presentation of the content]

Content requirement:
The connotations of color and other presentation-properties constitute
non-text information and must (per 1.1.1) be afforded text
explanations that are associated with the items bearing these
presentation effects (and connotations), associated by an association
that can be programmatically determined.

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

The group thinks that situations where the density of the color would
affect the information in such a way that it is too subtle or
complicated to be visually rendered in another way, are extremely
rare.

UAAG 2.3 applies to conditional content, and is not equivalent to
necessary information that a color blind person can't access.
The DAISY player example of minimizing notes is a different issue
because they are not equivalents to content. They are enhanced
information, so it makes sense that people should take extra steps to
access that information. The group does not think color blind people
should be required to go elsewhere to get basic information in
circumstances such as those covered in this success criteria. Color,
as it applies to this success criteria, is often text based
information, and therefore would not be covered under SC 1.1.1.



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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1203)

"content is perceiveable" is an oxymoron; the content may be
unrecognizable if the features of the rendered presentation are not
perceivable, but perceivable features are not an independent
principle, they are just a possible failure mode for the success which
is understanding what was being represented in the rendered content.

Understanding is an independent requirement, perception is an
instrumentality.  Compare with how people can frequently read text
where all but the first and last letters of each word are obscured
beyond recognition.  This rendered content would flunk a 'perceivable'
test but pass a 'recognizable' test thanks to the inherent redundancy
of natural language.

The whitespace between glyphs is either perceivable or not
perceivable.  The functional requirement if the glyphs are spelling
some natural langugage is that the user be able to recognize the
natural language represented by the glyphs in the rendered content.
The term 'recognizable' is a significantly better fit to the
requirement, here, as opposed to 'perceivable.

Proposed Change:

Change to [words to the effect that]

"information is recognizable in the rendered content at the user
interface -- a) [best] as configured to be presented by the author and
server b) [good] as presented in a delivery context where the user
employs readily-achievable adjustments to the look and feel or c) [OK
when that's all that works] c) as available in a readily discovered
and followed alternate path through the content."

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

Principles are not a technical provisions, but something to provide a
gestalt. We have changed them to a certain extent but we want them to
be short slogans that are easily remembered and understood as
overarching principles.

They now read:

1. Perceivable - Information and user interface must be perceivable by the user.

2. Operable - User interface components must be operable by the user.

3. Understandable - Information and operation of user interface must
be understandable by the user.

4. Robust - Content must be robust enough that it can be interpreted
reliably by a wide variety of user agents, including assistive
technologies.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1204)

The principle is that "what one can do, others can do."

Interactive objects are an instrumentality, an intermediate level of
representation.  The content can succeed by affording equivalent
facilitation for widgets through menus or other widgets or voice
command.

Proposed Change:

There are two principles here:

1) What one can do, others (PWDs) can do.  [This is more likely the
section head for device-independent interaction etc.]

2) Afford remediation [restore a usable look-and-feel] with as little
deformation of the look-and-feel as possible.   [This is probably a
separate, cross-cutting section explaining why color coding should be
_visually evident_ where readily achieved, etc.]

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

We believe that those two principles are too abstract. We believe that
the current structure is more salient.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1205)

Seizures are actual harm to the user independent of whether there is
any value in the Web content there to be accessed.  True, the seizures
can prevent access to value in the content but before one even gets
there there is harm done.

Proposed Change:

Break out a separate "first, do no harm" principle and put 2.3 under
it. Introduce no impediments to people citing or implementing this
provision as severable from any of the rest.

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

This makes sense, but we don't want to have a principle with only one
provision under it. We have, however, added the following conformance
criterion:

 Non-Interference:  Use of any technologies that are not
accessibility-supported content technologies does not interfere with
use of the accessibility-supported content technologies used to
conform to these guidelines. Specifically, content meets the following
criteria even if the content uses non-accessibility-supported
technologies:
   1. No Keyboard Trap: 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.
   2. Flash Threshold: To minimize the risk of seizures due to
photosensitivity, content does not contain anything that flashes more
than three times in any one second period, or the flash is below the
general flash and red flash thresholds (see Success Criterion 2.3.1).
   3. Non support: The content continues to meet the conformance
requirements when the (non accessibility-supported) technology is
turned on, turned off, or is not supported by a user agent.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1206)

Good; but there are a few things mis-filed

Proposed Change:

move 3.2.5 to a "what user can do" section containing most of the
Principle 2 material.

Move Guideline 2.4 to a "what the user needs to be able to understand"
section containing most of what is presently Principle 3 material.

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

SC 3.2.5 isn't a problem with inability to operate, but a problem with
disorientation.

Regarding Guideline 2.4, these criteria do fit in both categories.
However, the working group feels these criterion have more to do with
operation than they do with understanding.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1207)

Compatibility with the future is a guaranteed "cannot complete a valid
Candidate Recommendation" clause.

PF definitely sympathizes with your desire to have the content create
a responsible document object model regardless of the AT uptake of the
information at the moment.  We want that to.  But the way to achieve
this is to have a concrete proposition as to the information that has
to be available in machinable form; not to say "anything the user may
infer from the rendered content must be encoded in a
machine-recognizable notation."  That isn't going to work.  The way to
success is, for example, take a label.  The requirement here is
indicated by the dialog:

Q1: Can the user do something, here?
A1: Yes.
Q2: what can they do?
A2:
Q3: what in the user experience tells them that?
A3: This .

If the association of A3 as label for the action is machine
recognizable, and the user should be able to recognize A2 from A3,
then we are done.

That is the general pattern to be replicated across the essential
information to answer questions of

"Where am I?"

"What is _there_?"

"What can I do?"

.. at a fine enough grain so that
the answers are always in the context
that the use can recall or associate
with their current place-in-browse (e.g. focussed object or reading cursor).

Proposed Change:

Build on contribution expected from IBM as to how to reword 4.1.  We
need to connect several things: information required for an 'informed'
user browse; machinable notations so UA can map to API the AT
understands; format specs that afford the ability to have a shared
understanding among author, author-automation, user-automation, and
user.

Spell out information requirements in Principle 3 -- what the user
needs to be able to understand (including about what they can do).

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

Thank you for your comment. We have removed the phrase to read: "The
goal of this approach makes it possible to apply WCAG 2.0 to a variety
of situations and technologies."

We have also added a section to Understanding WCAG 2.0 titled,
"Understanding the Four Principles of Accessibility." which includes
additional explanation about the principles.

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

Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5]
(Issue ID: LC-1208)

equivalent facilitation does not only apply to future technologies, or
only to technologies outside your baseline.
This is a principle that applies across the board.

Compare with comments on "one strike and you're out" roll-up in the
comments on the conformance scheme.

Proposed Change:

re-write the document and conformance scheme so that it is obvious
that the remedy for a potential problem may come at a different level
of aggregation from where the potential problem was noticed.

For example, a CAPTCHA in the login process may be worked around by a
totally different login process.  In other words the failure of access
is local to the image but the affordance of accommodation or relief is
through equivalence at the task, not the image, level.

For another example, a diagram in SVG may afford the user a navigable
structure of focusable elements.  If these represent the notional
objects in the scene, and they are suitably titled and otherwise
annotated with properties and relationships, the text equvalent for
the image may be provided at a lower level of aggregation by providing
text associated with the parts of the image.

So the relief may be at a higher or lower level of aggregation from
the perception of a possible problem (recognition of a match to the
selector or applicability-condition I would call the "left-hand-side"
of a rule e.g. success criterion).

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

Currently there is no requirement that the work-around be at the same
level of aggregation on a web page, as long as it is on the same page
(see definition of web page) so equivalent facilitation is permissible
at a different layer of aggregation (as long as it is at the same
URI). For instance, in the case of the CAPTCHA example you gave, the
different login process would conform as long as it could be reached
from where the CAPTCHA is situated.

Received on Thursday, 17 May 2007 23:27:30 UTC