W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2006

Re: Key bindings... (user agents - was accesskey was ...)

From: Orion Adrian <orion.adrian@gmail.com>
Date: Wed, 11 Jan 2006 08:24:47 -0500
Message-ID: <abd6c8010601110524w2af9c33cp95cc98493e3d3436@mail.gmail.com>
To: w3c-wai-ig@w3.org

On 1/10/06, John Foliot - WATS.ca <foliot@wats.ca> wrote:
>
>  Charles McCathieNevile wrote:
> >
> > And the HTML and similar groups should leave that bit of markup alone,
>
> > fix  their specifications, and let us move on to deal with other
> > problems. (And  my good mate John should see the light and stop
> > worrying about the key  attribute so much, in order to concentrate on
> > getting rel right. But he'll  keep on with both, I guess ;)
> >
>
> When a foolproof method exists to avoid tom-foolery such as:
>
>   "Acc<span style="text-decoration:underline;">e</span>ssibility"
>
> ...then I will rest.  The continued problem with author proposed keys is
> that the author will then set about telling the end user which key it is
> - this is simply human nature - why else choose a specific key if you do
> not plan to share that info?  And if they get it wrong, the same old
> issues as before crop up.
>
> Declare the intent, and leave the end user mechanism to the end user:
> remember too that we are talking about more than just user agents here,
> there is also the Adaptive Technology layer for those users who need it
> and they often have keystroke requirements as well.
>
> So it's a balancing act between author rights and needs and user rights
> and needs, between "nice to have" features vs. "possibly really getting
> it really wrong" frustration.  I argue for the least harm principle.
> Chaals has admitted "...the value inside, the hinted key, may even be
> useful at times. Although that's the *least of its benefits* (emphasis
> mine), and the thing that has caused most of its problems."
> (http://lists.w3.org/Archives/Public/w3c-wai-ig/2006JanMar/0027.html),
> and further stated that any author who proposes a key without getting
> the role/rel aspect correct should be "slapped" - a sentiment I share,
> but my frequent flyer points cannot support.  How do we ensure that
> developers don't do this very thing? I suggest you take away @key and
> leave them the rest - you can't break what you can't touch.

Funny. I feel the same way about formatting and layout. I'm wishing
for a world where content authors simply write and the browsers do all
the layout and formatting. My question is, why doesn't the same
philosophy apply towards formatting and layout?

--

Orion Adrian
Received on Wednesday, 11 January 2006 13:24:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:24 GMT