Dropdown > 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 Dropdown component in all variants and states in order to provide more documentation on the component’s page in Pajamas and address any items that need fixed.

## Initial 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.

### Methods

- Visual scan
- Code/semantics review
- Keyboarding text
- Screen reader test

### Tools

- NVDA + Chrome version 92
- VoiceOver + Safari

## 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 completed task here indicates that testing has been done, not that the result was passing.

* [x] All actions and functionality can be done with a [keyboard](https://design.gitlab.com/accessibility-audits/2-keyboard-only).
* [x] Links, buttons, and controls have a visible [focus state](https://design.gitlab.com/accessibility-audits/2-keyboard-only#focus-states).
* [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] Changes in a component’s state are announced by a screen reader. For example, changing `aria-expanded="false"` to `aria-expanded="true"` when an accordion is expanded.
* [x] Color combinations have [sufficient contrast](https://design.gitlab.com/product-foundations/colors#accessibility).

## Results

**Watch recordings  of the audit** (internal)

1. [▶︎ Intro](https://drive.google.com/file/d/1dNbOpgUOJb6s8R8r01gdXU9J9gs2XdQO/view?usp=sharing)
1. [▶︎ Visual scan](https://drive.google.com/file/d/1qCB9-KfC1p-D7ao0QiwzQQMehERZZvUS/view?usp=sharing)
1. [▶︎ Code and semantic review](https://drive.google.com/file/d/1z-Epc8tTuH32PzPq6Pr9jrOqI9KKXbNx/view?usp=sharing)
1. [▶︎ Screen reader demo](https://drive.google.com/file/d/12K20wzxrMuMrAq4T4HNXC_MiDXhE8NlO/view?usp=sharing)

| **Problem** | **Solution** | **Related Issue/MR** |
| ----------- | ------------ | -------------- |
| From the visual scan, I don't think there are any large issues, but I would like to consider the focus ring in general based on potential forthcoming WCAG updates. [This article](https://www.sarasoueidan.com/blog/focus-indicators/) summarizes it well. | Explore global updates to the focus ring. |                |
| In general, the way the dropdown is currently built is too prescriptive to a _menu_ and is not appropriate for all of the [use cases](https://design.gitlab.com/components/dropdown#usage) a dropdown should support. This will be explained further in the related issue. There are also issues with the code semantics/structure of the current dropdown. | Provide examples of different types of dropdowns, along with semantic differences, that support each type of use case.  |                |

## 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:dropdown"

Story points: 3.0