swagger-api / swagger-api/swagger-ui

Dialog accessible focus handling

Open
#5,308 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
29k
Forks
9.3k
Avg merge
2d 23h
Merged PRs (30d)
25

Description

This issue relates to the fourth point on #5290, and expands on possible solutions:

The authorization dialog needs to be updated in the following two ways to be accessible:

  1. All content obscured by the modal needs to be the child of an aria-hidden parent to prevent screen readers from accessing it
  2. It needs to prevent focus from moving into the background page

aria-hidden & portals

To make both of the above easier (but primarily for the second point), I would suggest making the modal container a sibling of the #swagger-ui container using portals. This is roughly the approach taken by the Reach UI dialog (relevant code here and here).

Focus management

Focus trapping can be addressed in one of two ways. The first option (that I quite like) is to use the inert attribute. This prevents focus from entering into any child element, and the resulting experience is more on par with a mouse user as it does not prevent a keyboard user from tabbing to the browser chrome. Inert still requires a polyfill, however, and that polyfill relies on mutation observers which may then need another polyfill depending on your supported browsers.

The other option is to listen to the focusin event on document.body, and send focus back into the modal whenever it leaves. This approach doesn't fit quite as well within the architecture of a react app, but it doesn't require any polyfills and is slightly more performant.

I'd be happy to work on the implementation, but since I'm not a maintainer or even a regular contributor I think it might be better for someone else to give opinions on the approach :)

Thanks!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the authorization dialog and the fourth point of #5290, then review the proposed Reach UI portal and focus-management approaches. The work is done when background content is hidden from screen readers and keyboard focus cannot move into the page behind the modal.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
accessibility, frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.