Description
MDN URL
https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Keyboard
What specific section or headline is this issue about?
Focusable elements should have interactive semantics
What information was incorrect, unhelpful, or incomplete?
This section recommends adding a keydown or keyup event to elements that can be focused using the keyboard.
However, some screenreaders and other tooling can swallow keyboard events,
notably Enter or Space and replace them with a click event,
which will break elements that don't watch for clicks.
What did you expect to see?
I would expect a hint that handling keyboard specific events might not be sufficient in some cases, for example because they might be replaced by the accessibility tooling.
Do you have any supporting links, references, or citations?
NVDA Screenreader https://www.nvaccess.org/download/
NVDA Github Conversation: https://github.com/nvaccess/nvda/issues/7898
JS Fiddle (taken from the conversation): https://jsfiddle.net/1m504ub6/1/
Do you have anything more you want to share?
While this might not be a common problem, I ran into this issue when debugging a flyout menu.
The menu uses mouseenter instead of click for activation, which is likely problematic itself.
To verify this behaviour:
- download the NVDA Screenreader
- open the JS Fiddle
- with the screenreader active, focus the button and press enter: this should produce a
clickevent - disable the screenreader, focus the button and press enter: this should produce a
keydownevent
MDN metadata
- Folder:
en-us/web/accessibility/understanding_wcag/keyboard - MDN URL: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Keyboard
- GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/accessibility/understanding_wcag/keyboard/index.md
- Last commit: https://github.com/mdn/content/commit/194bd13942ad0c532c92d364e0d5d0c36732d98c
- Document last modified: 2024-07-25T21:02:22.000Z