- From: <bugzilla@jessica.w3.org>
- Date: Mon, 11 Oct 2010 21:23:00 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10994 --- Comment #4 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2010-10-11 21:22:59 UTC --- 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 11 October 2010 21:23:02 UTC