Re: Are we really still talking about Access Keys?

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?

NavitageToHome
NavigateToContent
NavigateToNavigation

Or in object-oriented land.

Home.NavigateTo()
Content.NavigateTo()
Navigation.NavigateTo()

along with

Search.Submit()

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