Accessibility concerns with Block Content modals

[tinykite]

When triggering a modal to open the image upload/editing interface within the block content editor (using the "edit" button that appears in the below screenshot), I noticed there is no focus management. A modal will open, but it will not trap a user's focus within the modal.

To be able to access the buttons within the modals (after toggling one with my keyboard) I needed to tab many times — through partially-obscured content behind the modal — to be able to access the buttons within the modal.

A common practice for accessibility is to capture focus within the modal dialog once it appears (so that a user won't accidentally navigate out of a modal, or have difficulty navigating into it).

Generally speaking, this also goes hand-in-hand with locking scrolling of the page, and focusing the first logically focusable element in the modal. Once the modal closes, focus should return to the button that originally triggered the modal.

There is a general example of this pattern in Adrian Roselli's blog , and it is a pattern that has also been adopted by the Adobe react-aria library and the Reach UI library, among other popular options for implementing accessible modals.

[KittyGiraudel]

I can also recommend a11y-dialog, an accessible dialog library I have been maintaining since 2016 which is recommended by Scott O'hara and Adrian Roselli. It comes with a React port which I also maintain. I have also authored a pretty comprehensive breakdown of react-a11y-dialog vs. other alternatives (such as @reach/dialog, @react-aria/dialog and @headlessui/react).