1

Problem Statement and existing understanding

I have a popup, which contains different kind of content separated into sections and is triggered on click of a button. I am trying to expose appropriate accessibility / aria semantics in this implementation. (It is not a modal dialog, but a simple in-place popup). As per my current research, this is what I think makes sense:

  • aria-expanded on the trigger button
  • aria-haspopup="menu" on the trigger button
  • role="menu" on the popup
  • role="menuitem" on the content inside the popup
  • other optional keyboard accessibility

Examples:

how it looks on twitter

code implementation

The WAI ARIA standard defines an actual role="menu" widget, but this is specific to application-like menus which trigger actions or functions. ARIA menus can only contain menu items, checkbox menu items, radio button menu items, radio button groups, and sub-menus.

Bootstrap’s dropdowns, on the other hand, are designed to be generic and applicable to a variety of situations and markup structures. For instance, it is possible to create dropdowns that contain additional inputs and form controls, such as search fields or login forms. For this reason, Bootstrap does not expect (nor automatically add) any of the role and aria- attributes required for true ARIA menus. Authors will have to include these more specific attributes themselves.

My problem is kinda similar but I need some help in deciding the menuitem roles.

Requirement:

This is how my popup menu looks like:

my requirement

  • there are 2 sections separated by a divider
  • the first section has some info and some interactive elements
  • the second section has links
  • for the second section, I am pretty much satisfied with using the menuitem role on each of them
  • I am not really sure about how to handle the first section though
  • As per current understanding:
    • anything wihtout the menuitem role inside a menu, is ignored for creating the accessibility tree
    • any children of the menuitem have their semantics removed. So, a button inside a menuitem would not be announced as such.
  • As with the twitter implementation, I can ignore my non interactive elements in the first section by NOT adding the menuitem role to them, but what should I do with the interactive elements. For example, for the Funds item, I can't add a role="menuitem" to the whole container, because then the Add Funds button would not work for screenreader users (?) .
  • I can may be add the role="menuitem" to the button, and make sure to add a better aria-label, which announces the current funds as well as allows user to click the button to add funds, but I am not really sure about this.

Questions:

  • Are there any other ARIA roles / accessibility semantics that should be applied in this case? Is this use case a menu which fits in the definition of role="menu" ?
  • If the role="menu" and role="menuitem" is most apt for this setup, what should I do with interactive elements in the first section of my component?
  • If my requirement does not fit in any of the popup roles, is it ok to not expose this with a aria-haspopup and only with aria-expanded ?

Other Resources:

TylerH
  • 20,799
  • 66
  • 75
  • 101
gaurav5430
  • 12,934
  • 6
  • 54
  • 111

1 Answers1

3

I'm a screen reader user myself, and by experience, menu-related ARIA roles are regularely unappropriate, leading to difficulties to use a page. So my best advice will be to don't use it in such a complex setup. Using aria-expanded is probably the most reasonnable, and certainly sufficient.

As soon as it goes further than quite simple items, it's no longer really a menu in the strictest sense, and screen readers have variable difficulties to make them usable and/or to give the correct information. A menu is supposed to be composed exclusively of items that can be activated by pressing on them, no more than that. Remember that ARIA was globally designed with native UI elements in mind. In a native (non-web) program, a menu can contain items and separators, that's all. So it should be the same here. By the way, the linked question says the same.

If you add more complex elements in your menu, the following questions come, and their answer aren't obvious at all:

  • Do I need to press enter to activate a text field inside the menu before starting to type into it ?
  • Do I need to press tab to reach a button or link inside an item ? And a text field or a select ?
  • How do I open and close a select inside the menu without activating the current choice ? Few people know Alt+Down/up arrow and much fewer implement them in their web components

Adding more complex items in menus gave ribbons in Office 2007+ and Windows 8+. They are nightmares to use with a screen reader. You never know if you have to press enter, tab, or just use arrow keys to reach what you want. So please don't reproduce this on the web.

QuentinC
  • 12,311
  • 4
  • 24
  • 37