Accessibility issue Templates for GitHub and GitLab

---
name: Accessibility issue
about: Report something on the site that people with disabilities find hard or impossible to use.
title: "Accessibility: "
labels: accessibility
assignees: ''
---

<!--
Template version 1.0, 2026-10-07, from https://auricartisan.com/templates/accessibility-issue/
Licence: CC0 1.0 (https://creativecommons.org/publicdomain/zero/1.0/). Copy it, change it and use it for anything; no credit needed.
Text between these comment marks does not show in the issue. Fill in what you know and leave the rest: you do not need to know WCAG to report a problem.
-->

## Summary

<!-- One or two sentences: what is wrong, and where. -->

## Where

<!-- The page's address, or the name of the screen in an app, and the part of it. Give the component's name if you know it. -->

<!--
Template version 1.0, 2026-10-07, from https://auricartisan.com/templates/accessibility-issue/
Licence: CC0 1.0 (https://creativecommons.org/publicdomain/zero/1.0/). Copy it, change it and use it for anything; no credit needed.
Text between these comment marks does not show in the pull request.
-->

## What this changes

<!-- What the pull request does, and the issue it closes, such as Closes #123. -->

## How to test

<!-- The pages or screens to open, and what to do there. -->

## Accessibility checklist

<!--
For the reviewer: tick each check you made on the pages or components this changes. If a check cannot apply, such as Images when nothing visual changed, write n/a and why after it. The numbers are WCAG 2.2 success criteria.
-->

- [ ] **Keyboard.** Everything that works with a mouse or touch also works with the keyboard alone, in an order that makes sense, and focus never gets stuck.
      WCAG: 2.1.1 Keyboard; 2.1.2 No Keyboard Trap; 2.4.3 Focus Order
- [ ] **Visible focus.** You can always see which element has focus, and no sticky header, footer or banner covers it completely.
      WCAG: 2.4.7 Focus Visible; 2.4.11 Focus Not Obscured (Minimum)

Licence: CC0 1.0 Universal, a public domain dedication. Copy, change and use these files for anything, including paid work, without asking or giving credit. The files are plain ASCII text in English, so they open the same everywhere.

1. Summary. One or two sentences: what is wrong, and where.
2. Where. The page's address or the app's screen, and the part of it, with the component's name if the reporter knows it.
3. Steps to reproduce. The fewest steps that show the problem, including the keys pressed or the words spoken.
4. Expected. What should happen, such as: the menu opens and focus moves into it.
5. Actual. What happens instead, in plain words.
6. Who is affected, and how. Who cannot do what, and what that stops them doing: the effect on people that the severity is judged by.
7. WCAG criterion. The number, name and level if the reporter knows them, such as 2.1.1 Keyboard (Level A). It can be left for triage.
8. Severity. Critical, High, Medium or Low, by the effect on people, with each one defined in the template.
9. Environment. The browser, the operating system and any assistive technology, each with its version, and settings such as zoom or reduced motion.
10. Screenshots or recording. An image or a short video; for a screen reader problem, a recording with sound or the exact words it read out.
11. Suggested fix. Optional: a fix, or a pattern to follow.
12. The pull request checklist. Eleven checks a reviewer ticks: keyboard, visible focus, names and labels, headings and landmarks, contrast, zoom and reflow, images, motion, form errors, an automated check and a screen reader smoke test.

The severity is Critical because the problem stops some people from doing a task, buying; the criterion's level does not decide it.

1. On GitHub, add the issue template. Save accessibility-issue.md in the folder .github/ISSUE_TEMPLATE/ on the repository's default branch. It then appears in the list of templates when someone opens a new issue. GitHub Docs: Configuring issue templates for your repository
2. Add the pull request checklist. Save pull-request-checklist.md as .github/pull_request_template.md on the default branch, and each new pull request starts with it. If the repository has a pull request template already, add the checklist to it.
3. Create the label. The issue template adds the label accessibility. Create that label in the repository if it does not have one, or change the labels line to a label you use.
4. On GitLab, delete the front matter. GitLab description templates are plain Markdown, so delete the block from the first --- line to the second. Save the files as .gitlab/issue_templates/Accessibility.md and .gitlab/merge_request_templates/Accessibility.md on the default branch, and people can pick them from the description template list. To add the label, put the quick action /label ~accessibility on a line of its own. GitLab Docs: Description templates
5. Triage each report. Check the severity against the scale, add the criterion if the reporter left it blank, and give the issue an owner and a date. Find the criterion in WCAG 2.2

• Accessibility audit reportA report with a findings register, severity by user impact, results by criterion and retests, and a workbench to fill it in.
• Remediation planA plan that turns audit findings into fixes with an owner, a priority, a due date and a retest.
• Acceptance criteriaGiven/When/Then criteria for common components, each tagged with its WCAG criterion, and a definition of done.
• Accessibility patternsComponents to copy for a suggested fix, with demos and WCAG 2.2 mapping