RE: Updated accesskey.next material

Léonie Watson wrote:
>
> The thing I like about author defined suggestions is that they're
> likely to be suited to the website/application, and therefore
> (probably) easier for people to learn.

A "maybe" that I will grant you - it's not an unreasonable supposition

> The counterpoint is the
> likelihood of the author defined suggestions remaining active, given
> the conflict resolution chain.

yep, coupled with i18n considerations: For example I've often used the
example of "Search" - many authors would consider it 'reasonable' to map
"Search" to "S", but what about if you are French (R for Rechercher) or
Spanish (B for Buscar)... Right away mapping "S" to Buscar makes
little-to-no sense - it is effectively random (although this particular case
perhaps not so much, Search being so common a thing). None-the-less if we
could declare the search feature 'hook' in the code, then user-agents &
users could handle the mapping externally - I would also love to see
re-usability factor in here: I should be able to go to *any* site and use my
learned keyboard shortcuts for at least the most common functions/features.

>
> "Another off-the-top thought: allowing to map hotkeys to any aria-role
> would provide us with two potential wins:
> a) it expands the ability to hot-key to anything, not just regions
> (landmarks)
> b) it expands the usefulness of the aria @role attributes, as designers
> who may not be thinking first about accessibility could still use aria-
> roles to achieve "mainstream" functionality, and we've often
> thought/stated that making ARIA about more than just AT would be a
> positive thing."
>
> Those would both be good things to achieve. I'm not sure it solves the
> same thing that accesskey could/should though?
>
> I think the appeal of accesskey is that it allows someone to target a
> particular instance of an element, not every instance of that element
> within the UI. Screen readers already have the capability to do much of
> what you suggest (which is very useful), but they come up against the
> same problem.
> It still takes time to locate the link/field/whatever you're after from
> a list of all links/fields/whatevers in the UI.

Yep... was typing faster than I was thinking there - good point. Still,
allowing binding to IDs would work, no?

JF

Received on Thursday, 20 November 2014 22:19:23 UTC