Accessibility audit workflow
Purpose
In &5387 we’ve set out to provide an accessibility audit for each GitLab UI component so that we may update the status and document any accessibility considerations on the component’s page in Pajamas.
This issue it to propose a workflow for addressing the problems uncovered during the audits.
Proposal
- Audit a component and document the results and solutions.
- Promote the audit issue to a sub-epic of the main audit.
- Create issues under the sub-epic and related MRs to address the problems uncovered during the audits.
- If the changes update the markup or behavior then we’ll have to evaluate the impact to existing components, including Vue, HAML, and Ruby instances.
- After all problems have been addressed, create a followup audit issue under the sub-epic to validate.
- Update the component’s documentation in Pajamas with accessibility considerations.
- Update the component’s status on the Component Status page in Pajamas. The status badge should link to the component’s audit sub-epic.
- Close the sub-epic.
Questions
- Is this workflow reasonable?
- How can we ensure that over the span of the audit and any updates other changes aren’t introduced to the component? In other words, putting some sort of freeze on it until the audit is fully complete.
- These efforts can take a lot of time, especially when considering changes that require manual updates, for example, in HAML and Ruby templates. How can we increase velocity?
- How could we standardize testing environments so that more people can help audit under the same circumstances with the same tools?