Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B bootstrap
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 263
    • Issues 263
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 114
    • Merge requests 114
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Bootstrap
  • bootstrap
  • Issues
  • #28295
Closed
Open
Issue created Feb 18, 2019 by Administrator@rootContributor

Dropdown does not conform to ARIA authoring practices

Created by: michaelwayneharris87

The dropdown widget (as of 4.3.1) does not conform to the ARIA 1.1 specification. That should present some accessibility concerns.

Per the ARIA 1.1 spec, when a button with aria-haspopup is set to true, the popup itself MUST have a role=menu, and should conform to the ARIA specification for the menu role. In general, the descendant options should have such roles as role=menuitem.

One solution would be simply adding the role=menu and role=menuitem to the dropdown and dropdown items. I'm hesitant to recommend that, however, as there is dropdown content such as headers, dividers, text, forms, etc. The ARIA spec isn't explicit, but I don't read it as allowing for the inclusion of that kind of content within an ARIA menu. None of the menu button examples in the ARIA 1.1 authoring practices include such content, for example.

Further, if you add role=menu and role=menuitem to the dropdown and dropdown items, you should take the menu items out of the tab focus order. The convention with ARIA widgets like this is that composite UI components should have only one focusable element, and arrow keys move focus within the component.

The other option may be to remove the aria-haspopup=true attribute altogether from the button altogether. In doing so, the dropdown stops following a menu button widget pattern and starts following a disclosure widget pattern.

In contrast to the menu, if you go this route, you may want to remove support for arrows to navigate among items, as there's no convention to moving focus through the focusable items of a disclosure using arrow keys.

A third option is instead of implementing half of each ARIA widget into the dropdown component is to create more discreet widgets, each of which adheres to the ARIA patterns more closely.

I'm not sure what to recommend, since it might mean rethinking how the component would work. But whatever direction you choose, you should become more in line with the ARIA spec than you are now.

Assignee
Assign to
Time tracking