Re: aria-kbdshortcuts feedback

On Thu, 25 Feb 2016 01:24:02 +0100, Dominic Mazzoni <dmazzoni@google.com>  
wrote:

> On Wed, Feb 24, 2016 at 1:14 PM James Craig <jcraig@apple.com> wrote:
>
>> In addition, an accesskey replacement spec would have the ability to
>> specify end use behavior (and event model changes) in a way that would  
>> be
>> inappropriate to do in an ARIA spec. Dominic, would you be willing to
>> pursue the solution in that spec rather than in ARIA?
>>
>
> I took a closer look. Current limitations of the accesskey spec that I  
> see:
>
> 1. It doesn't require the user agent to activate the element, it's  
> allowed to just focus it. That means that if a web app currently has
> shortcuts that activate something, switching to accesskey wouldn't
> achieve the same thing.

Dominic already noted this as an issue.

My suggestion is that the spec say user agents *should* activate, but  
*may* only focus instead.

Rationale:
1. Some users want that safety
2. In the case of one accesskey value being applied to multiple elements,  
this enables a user to cycle between them - sort of a cheap way of having  
a local tabindex set.

This works today in Internet Explorer (and has done for years).

But I agree that the common case is the accesskey should just activate the  
control, and I'll edit to clarify.

> 2. Accesskey still only allows you to specify a single key, the user  
> agent chooses the modifier keys. This wouldn't help a web app that
> wants to trigger when you press an unmodified key, or a web app that
> wants to listen for a specific shortcut.
>
> Here are some examples of real-world shortcuts on six popular sites:
> * 'C' to compose a new message in Gmail/Inbox
> * Ctrl+Shift+C to do a Word Count in Google Docs
> * Shift+A to "reply all" in Yahoo Mail
> * 'L' to like the current story on Facebook
> * '/' to focus the search box on Twitter
> * 'C' to create an issue on GitHub
>
> The accesskey spec doesn't support *any* of these.

Actually, the spec supports them all. There is nothing to stop an  
implementation from using the bare key, although as far as I know only old  
mobile browsers and iCab ever did.

This is not entirely a bad thing. In some cases, I already have commands  
assigned to keys, and a website that does something different with them  
(twitter is a key offender here in my life) is confusing and leads me to  
do things I did not want to do.

This was a key historic objection to accesskey. Using javascript to  
enforce such anti-user behaviour isn't a step forward for actual users,  
however much developers find it convenient :(

However, it would be good to give developers more power to *request* a  
particular shortcut. Right now, any author using the HTML5 version of  
accesskey is in fact *reducing* access compared to using the HTML 4  
version.

Yandex mail allows "w" and "ц" for composing a new message. Although HTML5  
supported that in accesskey, as e.g. <button accesskey="w ц"... in most  
browsers except IE that leads to *no* accesskey being assigned. It works  
better in reality for authors to assign a single key, and user extensions  
to replace them according to preference.

Similarly, a user extension can easily take a list of the accesskey values  
supplied by the author and make them work as bare keys, or whatever  
modifier the *user* prefers - something that can't readily be done if the  
app uses javascript to implement shortcuts.

If we allowed more than a single character value (as HTML5 does, but which  
breaks in all browsers except IE and maybe Opera presto) we could use  
shortcuts like command-backspace, alt-space, or up-then-left. But the  
relevant browser bugs should be fixed first, or we'll be doing something  
theoretically great. But breaking the actual web in practice.

cheers

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Thursday, 25 February 2016 14:23:06 UTC