search

it-vegard / a11y-reference-website

An example website, built with the option of switching between accessible and inaccessible versions of individual parts. Meant for use as a reference, and for educational and testing purposes.
MIT License
7 stars 2 forks source link

Focus management in dropdown component #21

Closed storsletten closed 4 years ago

storsletten commented 4 years ago

The dropdown component uses aria-haspopup="menu", which means screen readers that use a virtual cursor will disengage that cursor to let the application handle navigation by arrow keys when the element is activated. Think of aria-haspopup as a promise that the application will handle keyboard navigation. For a menu, this means supporting navigation by arrow keys. This issue can be addressed in one of two ways:

  1. Remove aria-haspopup from the dropdown component. When only aria-expanded is present on a button, it will appear like summary and details elements to a screen reader end user.
  2. Implement proper focus management in the dropdown component. This includes setting initial focus on the first element when the dropdown pops up, as well as adding keydown event handler to support navigation by arrow keys within the dropdown.
it-vegard commented 4 years ago

Thank you so much for the feedback. It is greatly appreciated!

I think we need to split the current component into two different ones, and choose solution 1 for the "Ruleset" dropdown and the shopping cart (add an item to cart from the product page), as that isn't really a menu dropdown (nor dialog, listbox or grid). The menu dropdowns ("Men" and "Women" dropdowns, plus language selector) should use solution 2, though.

Would you agree on my conclusions above?

I'll prepare a PR on this as soon as possible, and post a link to a preview on how it will work. (Love deploy previews in Netlify!)

storsletten commented 4 years ago

Yes, that sounds good.

it-vegard commented 4 years ago

After initially building two versions like described above, I stepped back and considered what most users might expect when navigating the menu. If I am not mistaken, the arrow key navigatio also requires the menubar/menuitem roles, which should be reserved for application menus, instead of navigation menus.

Because of this, as well as my assumption that most users would try pressing tab instead of using the arrow keys to navigate the dropdown menus, I went with the simplest solution for now, just removing aria-haspopup for all dropdowns. (Alternative 1 above)

We will do user testing later, and if anyone comments on this, I'll of course reconsider this approach.

I hope you consider this a sufficient approach!

storsletten commented 4 years ago

Yes. Since the dropdown appears right after the button in the DOM, aria-expanded will suffice here. If the dropdown and the button had been located on different parts of the page (e.g. dropdown being appended to the end of body), then a technique involving aria-owns would have been needed to establish a relation between button and dropdown. I wish I could say aria-controls, but since screen readers don't really support it, it wouldn't have had the desired effect. The aria-controls attribute is a sad chapter in the history of ARIA, but that's a topic for another discussion.