xref: https://github.com/github/accessibility-audits/issues/4030
xref: https://github.com/github/accessibility-audits/issues/4031
xref: https://github.com/github/accessibility-audits/issues/4055
xref: https://github.com/github/accessibility-audits/issues/4066
xref: https://github.com/github/accessibility-audits/issues/4321

Description

This PR adds a role of alert to the dialog error banner such that it will be announced immediately on showing it. I believe it meets the accessibility criteria.

Some more thoughts:
(Does not appear below is required for MAS-C, that is why I did not attempt a refactor in this ticket - may open up another issue to track this as potential improvement)

The dialog error banner is used two ways. 1) To display an error as a user is typing. 2) To display an error upon form submission.

For #1, It seems like it might make sense to also implement our <AliveContainer> and pass it input to watch so that the user is informed on debounce - right now it can be interrupted by continued typing. But, I also wonder if it would make sense for us to use the primer "error" under the input for this since it is directly related to a single input. https://primer.style/design/ui-patterns/forms/overview#validation

For #2, there is an accessible form convention that on form submission and failure that the error message banner or "flash" receive focus. One of the accessibility tickets mentions this as an option and provides this documentation on it. My assumption is this is more friendly to braille users who may not get the screen read announce.

Also related is that a more accessible pattern for form submission is to not disable the form submit button when in an error state, but on submit will focus either the banner error and re-announce or if no banner focus the first input that is in error and re-announce.

Screenshots

Release notes

Notes: [Improved] The aria role of alert is applied to dialog error banners so they are announced by screen readers