An accessibility audit issue reporting template

Page title
This is useful when discussing the page later and should generally be the title visible on the page itself (rather than the title from the browser tab) as this makes visual mapping easier.
Page url
The full url of the page (including any querystrings if present)
Page state
If the page was in a particular state, describe that here, for example an error state, or having chosen certain options.
Journey and step
If this is part of a mapped user journey, detail which journey this is and the step number.
Environment
For example live, staging or development (this might be obvious from the url below)
Browser
Type and version number - important as browser type can have a great effect on how a screen-reader responds but it and the version can impact on interface behaviour
Viewport
The width of the browser window - this can be in general terms (eg mobile, tablet, desktop) or more specific if the issue requires it (eg 1400px wide)
Operating system
Type and version - as above this can have an effect on the outcomes
Other software
Record any other software being used, for example if using a screen-reader, or speech recognition. Include the version number.
Description of the issue
Detail the issue as much as possible. Remember the person reading this will be seeing this cold, so be as clear as possible. Include how this issue may affect users.
Priority
If this fails one or more WCAG criteria indicate which (for example “WCAG A 1.1.1 Non-Text Content”). It can be useful sometimes to add a quote from the criterion depending on the intended audience. If it is not a WCAG fail then assign one of the following:
Steps to reproduce
Especially if the page needs to be in a particular state, detail how someone can get to the point where they can replicate the issue found.
Screenshots and video
Add as many screenshots and video screen captures of the issue as possible. Videos are very effective in demonstrating an issue, especially for screen-reader issues. When using screenshots, include devTools if appropriate and annotate the screenshots to bring the attention to the issues being shown.
How to fix the issue
As the person picking up the ticket may not have experience it is helpful to provide a solution or options of how the issue may be fixed. Depending on the issue this may require code snippets, a direction to discuss something with a UX or content designer, or a reference they could use to learn more, but we should strive to always provide guidance.
Acceptance criteria
Indicate how the fix can be tested to ensure it works. The level of detail will depend on the issue so this can be anything from running an automated checker to a set of steps to follow with a screen-reader.