-
Notifications
You must be signed in to change notification settings - Fork 40
Focus menu items with aria-activedescendant #43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Leave DOM focus on the summary that opened the menu or a filter input inside the menu. Navigating items with arrow keys should not move focus away from the input field.
A menu with a filtering input at the top cannot itself be role=menu because it hides the input from screen readers. The following relationship is required. <details-menu role="none"> <input> <div role="menu" aria-activedescendant="i1"> <button id="i1" role="menuitem></button> </div> </details-menu> Managing focus with aria-activedescendant requires the attribute to be attached to the role=menu element in order for the focused item to be announced.
const subscriptions = [ | ||
fromEvent(details, 'click', e => shouldCommit(details, this, e)), | ||
fromEvent(details, 'change', e => shouldCommit(details, this, e)), | ||
fromEvent(details, 'keydown', e => keydown(details, this, e)), | ||
fromEvent(details, 'toggle', () => clearFocus(details, this)), | ||
fromEvent(details, 'toggle', () => identifyItems(this), {once: true}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean runtime mutations of the HTML will break focussing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we discussed this approach, I wasn't sure how it would work, because according to the spec:
Instead of moving DOM focus among descendant elements, authors MAY set DOM focus on an element that supports
aria-activedescendant
and then usearia-activedescendant
to refer to the element that is active.Authors MUST ensure that one of the following two sets of conditions is met when setting the value of
aria-activedescendant
on an element with DOM focus:
...
It suggests that aria-activedescendant
would be set on an element that's receiving DOM focus, which was why in #38 it was set on the input.
It seems like this implementation does work with VoiceOver. However, in NVDA it reads out the focused input's text instead:
NVDA requires the element with DOM focus to manage the active descendant. We use summary or an optional input field as the focused element. Co-authored-by: Mu-An Chiou <[email protected]>
Co-authored-by: Mu-An Chiou <[email protected]>
Replaces the DOM focusing of menu items with
aria-activedescendant
. This allows menus to contain other focusable elements, like<input>
, that don't lose focus while navigating menu items with arrow keys.A menu with a filtering input at the top cannot itself be
role=menu
because it hides the input from screen readers. The following relationship is required.Managing focus with
aria-activedescendant
requires the attribute to be attached to therole=menu
element in order for the focused item to be announced.This is similar to #38 but differs in that there remains only one method of focusing menu items and the menu is unaware of its contents, which may or may not include an
<input>
field.