The accesskey attribute, despite its potential utility, is fraught with numerous issues that limit its effectiveness and
usability:
- Screen readers' implementation of
accesskey largely depends on the browser used, as they rely on browsers for much of their
functionality. Some screen readers may repeatedly indicate the accesskey value each time the element is encountered, potentially
causing unnecessary repetition and noise for the user.
- Conflicts between
accesskey shortcuts and other keyboard shortcuts, such as those of browsers, operating systems, assistive
technologies, or browser extensions, are frequent. This overlap can lead to uncertainty and potentially trigger unintended actions, causing user
confusion.
- While keyboard shortcuts are vital for screen reader functionality, conflicts can disable either the screen reader or
accesskey
shortcuts. Typically, screen reader shortcuts take precedence, disabling the accesskey but preserving screen reader functionality.
However, this can cause confusion for users attempting to activate an accesskey.
- No keystroke combinations can guarantee zero conflicts with all browsers, assistive technologies, or operating systems, particularly
considering foreign languages. For instance, an
accesskey shortcut that works in an English browser may conflict in the same browser
set in another language due to different menu naming conventions.
- While using numerals instead of letters for keyboard shortcuts could reduce conflicts, it’s not a foolproof solution. There’s no standard
correlation between numbers and web functions, which could lead to user confusion.
- Unlike the Windows environment that highlights keyboard shortcuts in menus, web pages or applications lack a standardized method to notify
users about available
accesskey shortcuts.
Given these concerns, it is generally recommended to avoid using accesskeys.
<div accessKey="h"/>
Do not use accesskeys at all.
<div />
