aria-kbdshortcuts and aria-linktype

Hi folksCan we coordinate this with the needs of the coga task force - see https://w3c.github.io/coga/issue-papers/links-buttons.html


These 3 proposals are all about the need to add more context. We should look at them as 3 usecases for the same solution.
 

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Thu, 25 Feb 2016 16:22:28 +0200 Chaals McCathie Nevile<chaals@yandex-team.ru> wrote ---- 

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