Dialog: Missing role and focus handling

[basham]

I'm testing the Dialog component, and I noticed some accessibility issues.

1. role="dialog" should always be applied to the dialog. It is missing when disablePageInteraction is enabled.
2. Focus should move to the dialog element when the dialog opens. Right now, focus remains on the trigger. Focus at least does return to the trigger upon close.
3. Focus should be trapped in the dialog. That means, tabbing from the last interactive item in the dialog moves focus to the first interactive item in the dialog and visa versa.

[pcberg]

@basham, these are rivet-react Dialog component bugs. Also, it looks like the focus issues are not present on adobe react-spectrum, so they appear to be an issue with our Dialog component (FWIW: Admittedly I didn’t test how the focus works)

[basham]

For the last couple weeks, I've been exploring if we could use the native dialog element, rather than the react-aria library to drive the Dialog component behavior. I found it to work fairly well, with minimal issues when testing with macOS Safari + VoiceOver and Windows Firefox + NVDA.

• Proof of concept (CodePen)
• rvt-dialog (CodePen)

However, it seems like the current recommendation of the Digital Accessibility Office is to not use this dialog element approach for now.

It is getting closer.

The major browsers mostly support it. The gotcha is how well the range of assistive tech supports it, too.

The process by which pretend becomes real in HTML-land is roughly as follows:

The new element or attribute is proposed and becomes a real thing in whatwg (aka the living HTML standard). Then some of the major browsers might implement their own vision of $thing. Then there will be months to years of PRs to fix defects in those implementations of $thing. Meanwhile (often after a very long pause) the makers of the various assistive technologies may begin to change their products to provide support for the shifting $thing, many of which are going to rely on the browser implementations becoming more stable. Rinse & repeat for a while — months or sometimes years. Then there is usually an announcement in accessibility circles that $thing is now a genuine and viable thing, and can be used well under certain cases. Then we verify that $thing actually works as expected against the list of tech we evaluate using, and make a go/no go decision.

We evaluate using:

• VoiceOver with Safari on iOS 17.0.x on iPhone 12 Pro
• VoiceOver with Safari on iOS 17.0.x on 3rd Generation iPhone SE
• Voice Control with Safari on iOS 17.0.x on iPhone 12 Pro 
• Keyboard only with Safari on iOS 17.0.x on iPhone 12 Pro
• TalkBack with Chrome and Firefox on Android 13 on Moto G Stylus 5G 
• TalkBack with Chrome and Firefox on Android 13 on Samsung Galaxy Tab S8
• Voice Access with Android 13 on Moto G Stylus 5G
• Voice Access with Android 13 on Samsung Galaxy Tab S8
• Keyboard only with Chrome and Firefox on Android 13 on Samsung Galaxy Tab S8
• Keyboard only with Firefox and Chrome on Windows 11 
• NVDA with Firefox and Chrome on Windows 11
• JAWS with Firefox and Chrome on Windows 11
• NVDA with Firefox and Chrome on Windows 10
• JAWS with Firefox and Chrome on Windows 10
• VoiceOver with Safari on MacOS Monterey 12
• VoiceOver with Safari on MacOS Ventura 13
• VoiceOver with Safari on MacOS Sonoma 14
• Keyboard only with Chrome, Firefox, and Safari on MacOS Monterey 12
• Keyboard only with Chrome, Firefox, and Safari on MacOS Ventura 13
• Keyboard only with Chrome, Firefox, and Safari on MacOS Sonoma 14

The current Dialog element issues in whatwg
https://github.com/whatwg/html/labels/topic%3A%20dialog

So our current evidence on Dialog element is it doesn’t work everywhere we need it to yet (modal and non-modal), and doesn’t support our minimum AT expectations (failing keyboard-only is a is a deal-breaker, since that ripples to other AT support).

We continue to monitor this one, but consider it to not be ready for primetime use at IU yet.

Given this, we agreed during today's meeting that we will just continue with the current react-aria approach and focus on solving the existing accessibility bugs — rather than attempting an entirely different approach.