RE: Are we really still talking about Access Keys?

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 12:38:12 UTC