Safari access-key bindings override Input Manager bindings

Originator:mo
Number:rdar://5331185 Date Originated:2007-07-12
Status:Closed Resolved:Yes
Product:Safari Product Version:
Classification:Other bug Reproducible:Always
 
12-Jul-2007 10:57 AM Mo McRoberts:
Safari (all releases of Safari 1, 2, and 3) bind access keys to “Ctrl+<key>”. For example, an HTML attribute of “accesskey="a"” would result in the access key being bound to Ctrl+A.

Mac OS X's Input Manager has traditionally bound certain functions to Ctrl+key functions, matching those key combinations used by the Emacs editor and other Unix utilities making use of Emacs-style keybindings.

Where access keys are bound to keys also bound by the Emacs-style bindings, Safari's access key bindings will take precedence. Obviously for many users this would be the desired functionality: users not coming from a Unix background wouldn't necessarily know about the existence of the Emacs-style bindings, and so they likely wouldn't be employed by the majority of users.

The consequences of the keys being unexpectedly re-bound are obvious: for example, if a user has typed a large amount of text (for instance, a bug report) and presses “Ctrl+A” to move to the start of the line, or “Ctrl+E” to move to the end of the line, and these keys have been unbeknownst to the user re-bound to anchors which navigate to other pages, the text the user has typed would be lost.

The solutions would either be to:

• Provide an option to alter the keybindings used by access keys (for example, a user could choose to bind to Ctrl+Shift)

• Provide an option to disable access keys altogether

The only alternative to the above options is the convince all web-site authors not to employ access-keys: as broken as their specification is, this isn't particularly practical!

24-Jun-2009 10:29 PM KIT CHEUNG :
Engineering has provided the following feedback regarding this issue:

The modifiers for access keys have been changed to Ctrl+Option (unless VoiceOver is enabled, in which case it's still Ctrl).

We believe this has been addressed in Safari 4.  Please verify with this build, and update this report with your results.

http://www.apple.com/safari/

09-Jul-2009 08:30 AM Mo McRoberts:
This issue has been verified as resolved and can be closed.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!