Modal keyboard interaction

[jgiardino]

The modal component should follow wai-aria authoring practices recommendations for keyboard interaction, specifically with regard to initial focus and keyboard support.

Several resources related to react and modals were included in #815.

Guidelines are available in the wai-aria authoring practices for Dialog as well as in the wai-aria Modal Dialog Example.

The keyboard interaction they describe seems pretty straightforward.

The guidelines for initial focus get a little hairy depending on the size and contents of the modal. They go into great detail on this in the Modal Dialog Example, under Accessibility Features, list item 2. Basically, the idea is to avoid having focus placed on an element that is off the screen which would force the first contents to scroll out of view. I’m not sure that there’s a smart way to handle this, so the best alternative might be to let the consumer identify which element will receive focus.

Any feedback and suggestions for this interaction are appreciated.

[jgiardino]

Related to this issue, some of us were reading the Accessibility chapter in the book Smashing Book 6. Here are some notes from a section in that chapter about disabling background content:

One of the most frequent focus management issues seen on the web is when focusable controls in background layers aren’t properly disabled. Keyboard or screen reader users can get lost navigating through content that’s visually hidden or obscured, but not actually disabled. This applies to side navs, modal windows, tab switchers, dropdown menus, navigation takeovers, and more.

To properly disable a control, you have a number of options, some more complex than others.
...
Is the background layer visible but dimmed, and/or covered with an overlay?

Traditionally, the steps required to disable a background layer include:

• Using a focus trap with JavaScript to keep the user’s focus inside the active content. But this isn’t always enough, especially in mobile screen readers. You also need to:
• Walk the DOM for your inactive content and put tabindex="-1" on each focusable item inside to remove it from the tab order. (Check out the helpers from ally.js.)
• Put aria-hidden="true" on the inactive content to remove it from assistive technology. This must be paired with the tabindex="-1" to avoid “ghost controls” with no accessibility information.

...
In reality, achieving the markup above can be quite advanced, especially for large pages — and particularly the focus trapping portion cross-platform. For this reason, I highly recommend using the HTML5 inert attribute being reproposed through web standards. With a polyfill, you can disable an entire region of an HTML page with a single attribute and no DOM walking. Just like with aria-hidden="true", which can’t be overridden further down the tree, it’s easiest to set inert on a sibling to your active content. Even with a polyfill, I can guarantee it’s a lot less work than the alternative of manipulating aria-hidden and tabindex on every focusable control.

Excerpt From: Smashing Magazine. “Smashing Book 6: New Frontiers In Web Design.” iBooks.

[jgiardino]

I just came across this example of an accessible modal dialog: https://github.com/edenspiekermann/a11y-dialog

At the end of the readme, there is a link to a react implementation.

[jgiardino]

I tried what @jschuler suggested regarding adding aria-hidden="true" via the dev tools to test across the three screen readers and see if this helps with trapping focus.

All screen readers (VO, NVDA, JAWS) ignored the contents contained in <div id="___gatsby"> after I added aria-hidden="true".

I did notice that I had trouble placing focus in VO initially. I was only able to use the rotor to place focus in the dialog. But when trying to navigate to the page contents from the address bar, it wasn't able to get to the dialog. This shouldn't really be an issue if we're able to place focus in the modal when the page loads.