(this is because a different discussion started morphing)
Keyboard shortcuts need to be configurable, for various reasons. They are important to various users. Common use case for them include
- “Enterprise apps”. Things that are heavy on “button pressing” like email systems, data management, accounting, etc.
- Browser extensions. Simple functions that are meant to enhance the browser functionality for some pages
- “Accessibility” use cases - for various reasons many users rely heavily on the keyboard (can’t see the mouse, don’t have the body strength to keep moving it around all day, etc).
Current mechanisms for describing keyboard shortcuts fall into two groups:
accesskey This much-maligned attribute has been somewhat improved in HTML5. It’s big benefit is that it is declarative - it is always visible through the DOM, which means it is easy for two or more scripts that interact to determine what has been assigned already. It is easy for browsers to make accesskeys configurable, allowing a user to reassign an accesskey to a shortcut that is useful although current browser implementation is generally not very helpful. Fortunately, the worst problems which caused it sometimes to be harmful have generally been fixed.
I recently wrote about this issue at more length, so I am not going to repeat it here, but think it is worth looking at further work on accesskey. The HTML Accessibility Task Force is also looking at the issue of focus management including keyboard (but there are other issues such as voice control).