W3C home > Mailing lists > Public > wai-wcag-editor@w3.org > January to March 2008

Consistency between 1.1.1 and 4.1.2 (and 2.4.6)

From: Bailey, Bruce <Bailey@Access-Board.gov>
Date: Fri, 8 Feb 2008 09:43:36 -0500
Message-ID: <23EB0B5A59FF804E9A219B2C4EF3AE3DDEB1C7@Access-Exch.Access-Board.gov>
To: "Ben Caldwell" <caldwell@trace.wisc.edu>, "Michael Cooper" <cooper@w3.org>, "Loretta Guarino Reid" <lorettaguarino@google.com>, "Gregg Vanderheiden" <gv@trace.wisc.edu>, "Andi Snow-Weaver" <andisnow@us.ibm.com>
Cc: <wai-wcag-editor@w3.org>

The team-wcag-editors-request@w3.org addy on my last message bounced on
me.

This question is inspired from our discussion last night about 4.1.2 and
how we otherwise consistently use "user interface component" throughout.

My new concern is that the first bullet to 1.1.1 has the term "control
or accepts user input", which implies something different than "user
interface component".  A control or (something) that accepts user input
is clearly just one example of a user interface component, and the
current definition explains that.

>  If it is a control or accepts user input, then it has a name that
describes its purpose.

Suggestion:  Change first bullet of 1.1.1 to:

> If it is a user interface component, then it has a label or
pragmatically determined name and role that describes its purpose.

(It makes it longer, but I think it probably necessary to consistently
keep "name and role" together.)

This takes the pressure off to change 2.4.6.  WCAG stills need all three
because 2.4.6 is Double A while both 1.1.1 and 4.1.2 are Single A.  With
the change above, 2.4.6 can stay the same because it goes a step further
by dropping the reference to programmatically determined name and role.

I am not thrilled to have so technical a bullet point in 1.1.1, but I do
not see a way around that.  The only other option I can think of might
be to incorporate labels into 4.1.2.  Using bullets to help with the
parsing:

4.1.2 Name, Role, Value:  For all user interface components:
* The name, role, states, properties, and values can be programmatically
determined.
* The purpose can be determined from the label along with the name and
role.
* States, properties, and values that can be set by the user can also be
programmatically set.
* Any notification of changes to states, properties, and values must be
available to user agents, including assistive technologies.
Received on Friday, 8 February 2008 14:39:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 December 2011 23:05:56 GMT