Dialog accessibility improvements

[yonikid15]

Description

Using Josh's Dialog requirements, make improvements to the Dialog component to improve accessibility and UI.

[mnigh]

@JoshBeveridge thanks for writing the requirements document for the Dialog component. I reviewed it and had few questions in regards to our implementation of it:

Dialogs should contain an <h1> element as the title. When the dialog opens, the user’s focus should be set to the <h1> element.

1. Our dialog has an <h1> element that is first read out on a screen reader, but is not the first item that is focused on since it's a non-interactive element. Is there a particular reason to ignore this warning?

The user should be able to close the dialog with the ESC key at any time.

2. The current design doesn't include a close button and I am not sure where a user would be escaped to since this modal is in the middle of the sign in process. Could you provide some guidance?

Also, if there are any other improvements that I have been missed, please make note in this issue, thanks.

[JoshBeveridge]

@mnigh I'm not sure if @yonikid15 passed this along to you, but the a11y issues with the dialog weren't just limited to the requirements in Figma (which will need to be updated once we figure out the other work required here).

To answer your two questions:

1. I'll elaborate on this below, but yes, for now, the <h1> doesn't need to be focusable.
2. You're correct - given the specific unique circumstances of this particular dialog, it shouldn't be escapable. Perhaps we have an option in the dialog component to disable that functionality?

I think the bigger issue with the dialogs is the way screen readers are accessing and navigating the content itself (hence my comment on the <h1> earlier), not the focusable items. I'm not sure if @yonikid15 was able to test this, but it might be worthwhile running through the dialog experience using your Mac's built in one. Happy to pair on this as well, so just shout at me if you'd like to take a peek.

[mnigh]

Dialog component uses third party library called reach.

[JoshBeveridge]

After chatting with @mnigh and @esizer, we settled on the following:

• generally, dialogs need an interactive element to be focused when first opened
• standard dialogs are different from alert style dialogs in that they shouldn't interupt the user's flow
• dialogs are expected to be treated similar to a standalone page

Given these things, we talked about doing the following:

• give ALL dialog elements a "focus content" style link at the very top, which will always be focused when the dialog is opened
  • similar to how pages have "skip to content" and "skip to nav" links, dialogs can have self-referring controls
  • this will ensure that the user's focus is ALWAYS at the top of the dialog's content so that reading order is consistent and makes sense
  • this also prevents focus from being sent to the bottom of long dialogs when the only interactive elements are the action buttons at the bottom
• migrate the auth dialog to the dialog-alert Reach element due to its deliberately interruptive nature