W3C home > Mailing lists > Public > www-html@w3.org > June 2005

Re: Are we really still talking about Access Keys?

From: Orion Adrian <orion.adrian@gmail.com>
Date: Fri, 3 Jun 2005 09:57:13 -0400
Message-ID: <abd6c801050603065711429f35@mail.gmail.com>
To: www-html@w3.org

Shouldn't we be talking about something more extensive than simply
mapped keys for elements?

Isn't this just simply another command in the grand scheme of things?


Or in object-oriented land.


along with


and the like.

The idea here is that each of these is a class that implements an
interface and instead of simply stopping at navigation, why not expand
it to it's natural conclusion and handle all commands.

Orion Adrian

On 6/3/05, John Foliot - WATS.ca <foliot@wats.ca> wrote:
> Charles McCathieNevile wrote:
> >
> > I agree that the author should not be setting "the" key to be
> > used.
> Hey! That's what I said...
> > But
> > since the author knows something about the random important
> > thing (it
> > shouldn't be a common enough function that there is a rel
> > attribute value
> > already defined, otherwise accesskey is the wrong tool for
> > the job that is
> > better done by the rel attribute). So they are the person
> > most likely
> > (IMHO) to have an idea of what might seem a useful mnemonic.
> ...and I am please to see this new attribute of "role"; it may in fact
> answer a lot of this issue.  The previous spec allowed for expansion of the
> rel attribute's values, but was painfully vague on *how* exactly
> (http://www.w3.org/TR/1998/REC-html40-19980424/types.html#h-6.12).  By
> observation most people just "made them up" and hoped for the best... For
> example, I have yet to see a formal profile (definition?) for <link
> rel="P3Pv1"... Even though the W3C has an automated checker for P3P policies
> (http://www.w3.org/P3P/validator.html). Oops...
> (Off Topic, if one does exist, can somebody point it out to me please?)
> >
> > The problem is that this key may not be available. Many
> > common letters
> > such as the range [a-zA-Z] are not so easy to get on an
> > arabic keyboard,
> > for example, and I will bet that fewer than 1 in 10 readers
> > of this list
> > know how to generate a hungarian double-accented-o in a way
> > that makes it
> > a feasible shortcut.
> Hey! Aren't these *my* arguments?
> > It is also true that a and A are,
> > according to the
> > current spec, two different accesskeys.
> >
> > So a part of any sensible answer (and this has been discussed
> > for years -
> > I am particularly upset that SMIL 2.1 still doesn't have it
> > in its new
> > candidate recommendation draft) is that the author proposes,
> > but the user
> > disposes.
> See, here's where I am concerned.  Why have the author propose anything;
> rather just mark-up the intent and leave it to the user agent to expose and
> allow the keystroke bindings?  This really shouldn't be *that* difficult,
> especially if, under most circumstances, the "role" being indicated is from
> the 'standardized' list.  Expanding that (by defining the "new" role via
> RDF) may be more taxing (I have visions of multiple look-up scenarios: load
> page, find RDF declaration - look that up- return it to user agent for
> subsequent end user exposure/discovery and then mapping... Seems onerous to
> me but I might be missing something)
> > Via their user agent in the first instance - the
> > user agent may
> > well re-map the keys to things that are commonly available in
> > the current
> > setup which it knows much better than the author.
> Yes... These are definitely *my* arguments <grin>.  Except for the concept
> of "re-mapping".  I suggest simply "mapping" based upon mark-up. Why have
> the user/user-agent undo something first?  Is it not more user friendly and
> less intrusive to simply "do", instead of "undo, then re-do"?
> > The onus is
> > then on the
> > User Agent to explain which keys are assigned to what, not
> > the author. In
> > addition, the user agent should (must if it is going to do a
> > good job)
> ...so let's insist on MUST
> > provide a mechanism for reconfiguring the keys, or otherwise
> > giving access
> > to just those things marked with an accesskey attribute.
> Well, given the wholesale re-working of this, perhaps seeing the return of
> "access" to a proposed attribute (as opposed to an element) might not be the
> better way, or dump the whole thing and just make the concept of "role" the
> hook that keystroke bindings could be mapped to.  It would force one and all
> to re-think, re-learn, re-address.
> Chaals, do you honestly see the browser manufacturers re-jigging to use
> accesskey differently?  I don't (well, maybe one, if you have any influence
> <grin>)
> >
> > The good thing about this approach would be that while it
> > requires changes
> > to the spec as written,
> Which I have said in the past.  But is this realistic?  Will W3C re-write
> parts of HTML 4.01/XHTML 1?  Highly unlikely... So work must be concentrated
> on XHTML 2, which is supposed to be a watershed Recommendation.  So, it
> brings me back to my point: ignore the broken attribute (or try repairing it
> - I am curious to see your idea reach fruition), and work for a real, usable
> solution in the next iteration (XHTML 2).
> > and fixing user agent
> > implementations, it doesn't
> > interfere with existing good user agent implementations and
> > it doesn't
> > require changes to the content of any existing conformant document.
> Well, here I would agree... Although I wonder out-loud how many web
> documents (in the grand scheme of things) already have accesskeys
> implemented?  And since the likelihood of *all* user-agents re-addressing
> accesskey is dubious, a strong argument could also  be made to walk away
> from "accesskey" and towards something new. (precedence: <strong> vs. <b>
> and/or {font-weight: bold;})
> >
> > Which is the friendly way to make the world better.
> Which, despite my apparent rage of yesterday is the real goal.
> > We are currently
> > looking at userJS and CSS to prototype some ideas for how to
> > make Opera's
> > accesskey impementation more useful - feel free to tell us about it.
> Feel free to consider me a beta tester.
> Cheers!
> JF
> --
> John Foliot  foliot@wats.ca
> Web Accessibility Specialist / Co-founder of WATS.ca
> Web Accessibility Testing and Services
> http://www.wats.ca
> Phone: 1-613-482-7053
Received on Friday, 3 June 2005 13:58:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:10 UTC