On the other hand, this is a useful feature, and axing it would be sad.  MediaWiki has to do a lot of guesswork here to create useful tooltips, which will fail on even slightly exotic browsers:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?view=markup#l237

The is_* variables there are basically just UA-string regexes.


All major browsers use a consistent key assignment scheme as far as I know, so that should normally add no information beyond the UA string.  People using obscure browsers are already easy to fingerprint.

The only people who would be more easily fingerprinted seem like they'd be people using weird configurations, where the accesskey is non-default -- but is this really an issue?  Surely there are lots of obscure configuration options in various browsers that will increase fingerprintability a lot.

If fingerprinting is an issue, the browser can ignore the user option's value when reporting the accesskey.  That will result in incorrect info being reported to the user by the website, maybe, but it's better than currently.


This feature would still be useful if it always returned some fixed prefix that depends only on the browser concatenated with the value of the accesskey attribute.  That would cover the large majority of cases.  If that's what's needed to avoid security problems, I think it's preferable to killing the feature altogether.

(I've also seen applications that just assume everything uses "alt-" as an accesskey prefix.)

(In reply to comment #1)
> All major browsers use a consistent key assignment scheme as far as I know, so
> that should normally add no information beyond the UA string.

The attribute takes a space-separated list of keys, and the browser can choose one of them, or another key altogether, or no key at all. This is a change from current browsers/HTML4, and if browsers implement that and make clever decisions based on the user's environment like the spec suggests, accessKeyLabel in turn exposes information about the user's environment that was not possible before.

That information is exposed anyway -- it's just a question of whether it can be harvested automatically or with some minimal user intervention.  If you want to see if the accesskey "a" is taken, just make an element with accesskey="a b" and get the user to hit Alt-A or whatnot and see if your element gets hit.  So it's not created only by accessKeyLabel.  Although some variant of that attack (the user-interaction-required one) might be doable now in at least some browsers, depending on how they assign accesskeys.

Also, I don't think authors will want to assign fallback accesskeys.  Accesskeys are meant as shortcuts for power users to memorize and be able to use reflexively, so they have to be consistent -- it's no good for them to change randomly depending on the presence of other accesskeys.  No native app does this kind of accesskey switching, right?  If there's a conflict, one of them wins and the other just doesn't work.

So unless there's evidence suggesting that this switching behavior is actually desired by authors, I'd say drop that in preference to dropping accessKeyLabel, if there's a conflict.  I already gave evidence in comment 1 that the latter would be useful to authors.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The increase in information leakage is far smaller than the increase in usability that will result from this feature, IMHO.

(In reply to comment #4)
> That information is exposed anyway -- it's just a question of whether it can be
> harvested automatically or with some minimal user intervention.

Yes. It's a lot harder to make the user press a lot of keys compared to just visiting a page (you'd probably need to test a large amount of accesskeys to get useful data).

> If you want to
> see if the accesskey "a" is taken, just make an element with accesskey="a b"
> and get the user to hit Alt-A or whatnot and see if your element gets hit.  So
> it's not created only by accessKeyLabel.  Although some variant of that attack
> (the user-interaction-required one) might be doable now in at least some
> browsers, depending on how they assign accesskeys.
> 
> Also, I don't think authors will want to assign fallback accesskeys. 
> Accesskeys are meant as shortcuts for power users to memorize and be able to
> use reflexively, so they have to be consistent -- it's no good for them to
> change randomly depending on the presence of other accesskeys.

The feature isn't meant to change randomly on the presence of other accesskeys, it's meant to change based on what device the user is using (full keyboard vs mobile).

> No native app
> does this kind of accesskey switching, right?  If there's a conflict, one of
> them wins and the other just doesn't work.

That still lets you detect information about the cross-origin iframe if the browser assigns an accesskey for that document and you later try to set the same accesskey.

> So unless there's evidence suggesting that this switching behavior is actually
> desired by authors, I'd say drop that in preference to dropping accessKeyLabel,
> if there's a conflict.  I already gave evidence in comment 1 that the latter
> would be useful to authors.

I agree that it's useful, although I also think that being able to assign fallback keys for mobiles (or letting the browser choose for itself) is useful. I'm just highlighting the issues I can think of.

I'm not reopening at this point since I still haven't thought this through completely. I'll probably revisit this when it comes to implementing it.

Bug triage sub-team assigning to Gregory to track with keyboard access issues. Dependency on 10888 is is the keyboard access requirements.

mass-move component to LC1

a11ytf decision to move to HTML.next:
http://www.w3.org/2013/10/17-html-a11y-minutes.html#item04

New bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23614

*** This bug has been marked as a duplicate of bug 23614 ***