RE: Consistency between 1.1.1 and 4.1.2 (and 2.4.6)

User interface components include both "controls or accepts input"  and also
displays.

In 1.1.1 we only wanted to include the 'control' part and not the display
half of UI Components.   Hence we did not use the UI Component language
there.   We do not usually require that there be a label on each paragraph
saying that it is a paragraph - we just require that the contents be
accessible.




Gregg
 -- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: Bailey, Bruce [mailto:Bailey@Access-Board.gov]
> Sent: Friday, February 08, 2008 8:44 AM
> To: Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg
> Vanderheiden; Andi Snow-Weaver
> Cc: wai-wcag-editor@w3.org
> Subject: Consistency between 1.1.1 and 4.1.2 (and 2.4.6)
>
> 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 16:46:28 UTC