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

LC-1200, 1203, 1204, 1206 disagree [was: Re: Your comments on WCAG 2.0 Last Call...]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 22 Jun 2007 22:29:44 -0400
Message-Id: <p06110417c2a22f8f5113@[]>
To: public-comments-WCAG20@w3.org

Comments inline

At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>Comment 31:
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[]
>(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
>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.

change to:

Information and operable objects must be presented to the use so as
to be perceivable.


User interface doesn't have to be peceiveable.  The user normally operates
on a mix of recall and recognition.  Actions that aren't needed often or are
usually remembered don't need to be presented for recognition as objects.
Actions of the UI must be discoverable, but not all perceivable until sought.

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


Couching this in terms of 'components' leaves out Navigation, which must
be operable (by keyboard and device independently).

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

change to:

Information and the operation ...

[otherwise it sounds as though this is just UI information, not all content

>4. Robust - Content must be robust enough that it can be interpreted
>reliably by a wide variety of user agents, including assistive
>Comment 34:
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[]
>(Issue ID: LC-1203)

(as per above)

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

(as per the above)

>Comment 37:
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[]
>(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

Let's go after this one with a parable.

Suppose the sustem motors the user through some navigation and
orients them to what it has done.  But the user didn't want to go
there, and can't go back.  Is this OK?  No.

So yes, there is a problem arising from overly agressive system initiative,
but the main thing it affects is the user's control of navigation.  The fact
that they can get disoriented is neither a necessary consequence nor
the primary concern in this failure mode.

The orientation is needed so the user can control where they go.
Not an end in itself.

Consider the game of 'statues.'  Sometimes disorientation is the
user's purpose in doing something.

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

Bypass blocks is operability.

Page titles is orientation; it is understandability of "where am I"

Logical focus order is understandability.  Content is presented
in an order that makes sense.

Link purpose is orientation, it is understanding "what can I do?"

2.4.5.  The meaning of 'locate' is undefined, and unclear, in this
statement.  It makes the SC unenforceably vague.

I think that you mean "multiple ways to find" or "multiple ways
to navigate to"

Find clearer language.

"labels descriptive" needs to be broken down to a more concrete
level.  But this is understanding, not operation.  It is understanding
"what can I do?"  Not being able to do it.

Guideline 2.4 treats Principle 2 as if it were "interactions are
manageable" not "objects/actions are operable."

Operable just means you *can do it.*  Not that you know when
to do it and when not to do it.  That's understanding.

2.4.7 -.9 are likewise all orientation, understanding of "where am
I?"  Not operability, not "can I invoke the relevant system action."

Received on Saturday, 23 June 2007 02:30:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:44 UTC