Broadcast message > 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 Broadcast Message 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 banner promotes awareness of a new feature or high-priority research initiative.

## 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 [broadcast message](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-broadcast-message--default) variants in GitLab UI.
* Visual review for contrast and states.
* Semantic and functional review
* Keyboard only
* Screen reader: VoiceOver + Safari on macOS
* Screen reader: NVDA + Chrome on Windows
* axe DevTools extension in browser

## 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] All actions and functionality can be done with a [keyboard](https://design.gitlab.com/accessibility-audits/2-keyboard-only).
* [x] Color combinations have [sufficient contrast](https://design.gitlab.com/product-foundations/colors#accessibility).
* [x] Broadcast is easily discoverable with screen reader. Since navigating headings is by far the most common way to find information ([source](https://webaim.org/projects/screenreadersurvey9/#finding)), and a broadcast message is static content on page load, and deemed important, it should probably have a meaningful heading.

## Results

| **Problem** | **Solution** | **Related Issue/MR** |
| ----------- | ------------ | -------------- |
| `role="alert"` is used, but per [WAI-ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices/#alert) "It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes." | Remove `role="alert"` since it's not the correct use here for static content present on page load. | TBD |
| No heading in broadcast message. As-is, without the broadcast being announced on page load, it's only discoverable when reading through the page content. | Since navigating headings is by far the most common way to find information ([source](https://webaim.org/projects/screenreadersurvey9/#finding)), and a broadcast message is static content on page load, and deemed important, it should probably have a meaningful heading. | 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:broadcast-message"

Story points: 2.0