RE: Proposal for 4.2, Ensure that user interfaces are accessible

Right.   But it is simpler than that.

As per previous post - we can just say "user input interface elements"  (or
components).  Or some such.

We just can't say "interface elements" and mean only input.  


 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

-----Original Message-----
From: [] On Behalf
Of Jason White
Sent: Friday, April 29, 2005 7:53 PM
To: Gregg Vanderheiden
Cc: 'Loretta Guarino Reid';
Subject: RE: Proposal for 4.2, Ensure that user interfaces are accessible

Gregg Vanderheiden writes:
 > Proposal 2: Replace "every element of the Web content" with "every user
> interface component of the Web content",  >  > GV:  GOOD  >  > then define
"user interface component" as any part of the Web content that  > can
receive focus and accept input from the user.
 > GV:  NOT GOOD.  User interfaces also provide information.  You need to  >
either change this to 'user input interface component'  or change definition
> to:  "any part of the Web content that conveys information to or accepts
> input from the user".  It's not as clean but we can't define user
interface  > as only input. 

Here's the problem: 1.3 already requires structure to be separated from
presentation, which in a markup language means providing explicit structural
elements. In general, this covers all of the elements used for output, that
is, for presenting information; and by requiring label, role, state and
value information we are now extending this to focusable user interface
controls. Perhaps this is implicit in 1.3 already but it deserves special
mention in the success criteria for the sake of clarity and completeness.

If we require role information for elements that present information as well
as those which accept input, isn't this tantamount to requiring it of all

If so, then there's a huge overlap with the requirement to separate
structure from presentation. What would be the role information for, say, a
paragraph element, and how would this differ from, or supplement, the
element type (namely paragraph)? If we restrict all of this to user
interfaces then we will have to define what a user interface is for purposes
of this success criterion.

Perhaps we could say that the success criterion applies only to
elements/components of the delivery unit that either accept input from the
user, or change dynamically in response to user input or external events.
This is where role, state and value are meaningful, whereas they aren't in
the case of a straightforward document or SVG image or other such static


Received on Sunday, 1 May 2005 04:09:50 UTC