Toast > Accessibility Audit

Refer to the [parent epic description](https://gitlab.com/groups/gitlab-org/-/epics/5387) for more information on this effort.

## Purpose

Audit the accessibility of the GitLab UI Toast component in all variants and states in order to update the Pajamas component [Status table](https://design.gitlab.com/components/status), and provide more documentation on the component’s page in Pajamas.

## Component description

A toast displays a short system message as a result of a user's action.

## Methods and Tools

Review the [initial testing methods in the parent epic](https://gitlab.com/groups/gitlab-org/-/epics/5387#initial-methods-and-tools). List the testing methods used for your audit below, including any additional testing methods needed for this component that is not listed in the parent epic.

* Evaluate all of the [toast](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-toast--default) variants and options in GitLab UI.
* Visual review for contrast and states.
* Semantic and functional review that assumes a [status](https://www.w3.org/TR/wai-aria-1.2/#status) role.
* Screen reader: VoiceOver + Safari on macOS
* Screen reader: NVDA + Chrome on Windows
* axe DevTools extension in browser) variants and configurations in GitLab UI.

## Audit Criteria 

Review the [general audit criteria in the parent epic](https://gitlab.com/groups/gitlab-org/-/epics/5387#audit-criteria). Add applicable criteria to this section, including any additional criteria needed for this component that is not listed in the parent epic. **A check indicates that the audit has been performed, not that it passes.**

* [x] [WCAG SC 2.2.1 Timing Adjustable](https://www.w3.org/TR/WCAG21/#timing-adjustable) (level A) must be satisfied. See [how to meet timing adjustable](https://www.w3.org/WAI/WCAG21/quickref/#timing-adjustable).
* [x] If the toast message is considered a status (`role="status"`) then it should have no interactive content within. As a live region, semantics are lost and the content is read as a single string. For example, if the current toast was a status it would be announced as "Undo. Close. This is a toast message."
* [x] If a critical message or action was referenced in a toast, it should be available permanently on the page as well.
* [x] A toast shouldn't receive focus.
* [x] All content is presented in text or with a text equivalent. For example, alt text for SVG, or `aria-label` for icons that have meaning or perform actions.
* [x] There should be no negative impact to a user or the experience if a toast is missed.
* [x] Color combinations have [sufficient contrast](https://design.gitlab.com/product-foundations/colors#accessibility).

## Resources

- [Defining 'Toast' Messages](https://adrianroselli.com/2020/01/defining-toast-messages.html), by Adrian Roselli
- [A toast to an accessible toast…](https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html), by Scott O'Hara

## Results

### Summary

After research, `role="status"` seems to be the best fit for a pattern, which will assume certain expectations and requirements for timing and function. [This example](https://scottaohara.github.io/tests/html-output/toastput-aria.html) seems to be the best reference for behavior (although the example mentions updates to make it more robust).

| **Problem** | **Solution** | **Related Issue/MR** |
| ----------- | ------------ | -------------- |
| Toast is using `role="alert"` and `aria-live="assertive"`. | Only use `role="status"` which has an implicit value of `aria-live="polite"`. | TBD |
| Toast is placed near the bottom of the DOM, making it difficult to move focus there fast enough to access the controls. | Don't include actions (link, button) within the toast message. | TBD |
| Toast can have critical actions in it. For example, "Undo". I think this would be a failure of WCAG SC 2.2.1 Timing Adjustable, since a user couldn't adjust timing to access critical functionality. The toast doesn't (and shouldn't) receive focus, so again, anything interactive within the toast isn't easily accessed. | Don't include actions (link, button) within the toast message. | TBD |
| Close button is before the toast content in the DOM, so it get's announced first. | Keep the close button outside of the `role="status"` and place at the end. | TBD |
| [Toast guidelines](https://design.gitlab.com/components/toast) promote including an action. | Update guidelines to not include an action. | TBD |

## Completing the audit

After the solutions have been explored and applied, review the [completing the audit section in the parent epic](https://gitlab.com/groups/gitlab-org/-/epics/5387#completing-the-audit). Complete all items prior to closing this issue.

~accessibility ~"Category:FE/UX Foundations" ~"component:toast"

Story points: 5.0