Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Closed
wants to merge 10 commits into from

Conversation

dgraham
Copy link
Contributor

@dgraham dgraham commented Nov 12, 2019

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.

<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.

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.

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.
@dgraham dgraham requested review from muan and a team November 12, 2019 21:54
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}),
Copy link
Contributor

@keithamus keithamus Nov 13, 2019

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?

Copy link
Contributor

@muan muan left a 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 use aria-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:

dgraham and others added 5 commits December 2, 2019 16:24
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]>
@dgraham dgraham closed this Apr 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants