Re: GUI baggage [was: Re: Role attribute values]

Hi Al,

I really don't think a small number of terms are going to take very
long for people to learn. But looking at the vocabulary so far, I
don't get the impression of a coherent list of values that have been
carefully structured to make them easily learned (other than the
rather obvious 'it's what everyone knows already', but that only
applies to the accessibility community).

In addition, as often seems to happen within the W3C, we don't seem to
make use of discussions that have happened in other arenas. In this
particular case, it's been a long time now that we've had the more
general event name "DOMActivate".

And similarly, XForms has been using <trigger> in preference to
<button> for quite a while, too.

I think it would be really good to bring some coherence to the W3C
user interface story, of which accessibility is of course, one part.

By the way, just to clarify one thing, in case there is a
misunderstanding; the reason for preferring slightly more abstract
versions of the 'controls' is not because of some 'purity', but
because when those controls come to be used in different contexts, it
can be very confusing for authors if the control name appears to bear
no relation to the way their particular target platform works. Making
the controls slightly more abstract really does make it possible for
*all* authors to acquire a knowledge of the vocabulary.



On 10/04/2008, Al Gilman <> wrote:
> [I don't claim to have processed the whole message, but I think I should
> clarify one point.]
> On 10 Apr 2008, at 8:39 AM, Roland Merrick wrote:
> >
> > This is the only term that caters for an affordance that enables
> user-triggered actions. "button" carries a certain amount of baggage in
> terms of preconceptions. There are many ways of enabling user action without
> the use of a "button" uless your definition is such that it covers all
> activation mechanisms. Since I am unsure as to your intent it is hard to
> suggest an alternative but perhaps "activator" might be close.
> >
> The implication in the comment is that the terminology should reflect the
> pure, presentation-unaware abstraction of the widget.
> That is not what we chose.
> We like the GUI baggage.
> The approach is to provide widgets that are full-function for use across
> presentation/activation diversity, but designate them with terms reflective
> of the GUI cliches that are their most familiar concretion, i.e. as
> most commonly bound to presentation.  These are the roles known in the
> accessibility APIs and they come there from a very thin deconstruction of
> the
> GUI.
> This, we believe, will allow more designers to learn the ontology fast and
> to use it correctly in their work.  They don't have to become experts in
> disability access or behavior modeling.
> Web designers make buttons look, statically and interactively, like
> physical buttons on the front-panel of electronic equipment.  They do this
> because the end-user will recognize what they are for more readily that way.
> And the end-user needs to know "what can I do?"
> We call them 'button' because the designers now think of them as buttons
> and we do better to build on what they know here, rather than give
> ourselves a need to re-educate them.
> Al
> /me, myself
> <disclaimer
> class="noConsensus">
> This is my personal interpretation of a theme through a
> lot of concrete decisions.  This is the first time the
> PFWG will have seen this particular explanation.  YMMV
> </disclaimer>

  Mark Birbeck | +44 (0) 20 7689 9232 | Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    EC2A 4RR

Received on Sunday, 13 April 2008 21:00:27 UTC