Skip to main content
Accessibility Report Requirements

How to document a report in accessibility tests

Markus avatar
Written by Markus
Updated over a week ago

For this special kind of testing, our regular bug form does not provide enough fields for all required information. Furthermore, additional requirements apply for accessibility reports on top of the requirements for regular bug reports formulated in the Bug Report Requirements and Bug Report Attachments academy articles.

Additional obligations that each accessibility report must adhere to are described in the following chapters. You can find two examples at the end of the article to showcase accessibility reports with applied rules.


Your bug title must meet the following format depending on the accessibility level (A or AA) and WCAG Success checkpoint:

Level A issues

Level AA issues

[A] [WCAG Success criteria]: <bug title>

[AA] [WCAG Success criteria] : <bug title>

[A] [1.1.1]: The meaningful image doesn't have alt attribute

[AA][4.1.2]: Sigh-out link announced without a role

The placeholder must be replaced with a description of your bug that you would use for regular bug reports. For example:

  • [A] [1.1.1] Social media links are announced incorrectly

Here are examples of bug titles for the most common accessibility problems. Feel free to use and adjust them for your purposes:

  • [A] [4.1.2] Sign-out link announced without a role

  • [A] [2.4.3] Filter toggle button announced with incorrect state

  • [A] [2.4.2] Page title is not unique and descriptive

  • [AA] [2.4.7] Focus outline is not visible for tester link below Sign-in button

Steps to reproduce

In general

First step: In addition to the call of the test URL, include the name of the tool you used in your first step. Replace the <tool> placeholder with e.g. NVDA, JAWS, WAVE, etc. in the following template:

  1. Using <tool>, open <test URL>, so e.g. Using NVDA, open

Multiple elements: If a checkpoint fails for multiple elements of the same type (e.g. button or link), group these repetitions in one report.

Multiple occurrences: To document multiple identical occurrences of an issue on the same page or on different pages, list them in your actual result under a section called “Other occurrences:”.

Described actions: Since visually impaired or blind people do not use a computer mouse, do not describe mouse actions. Instead, describe keyboard and touchpad actions, such as:

  • Use the TAB key to navigate to User Account

  • Press the ENTER key to activate Sign out link

  • Swipe left to focus hamburger menu

Automated tools: You are welcome to use tools like WAVE to identify problems, but your report, including your steps, must be described from a user's point of view. You may not describe in your steps how you use an automated tool and what it reports, but must rather describe everything as if you had not used any tool but simply based on the WCAG checkpoints.

Color contrast issues

Your steps must be the following (replace placeholders):

  1. Open <test URL>

  2. ...

  3. ...

  4. Measure the color contrast ratio of <element name>

Problems with the same color set may only be reported once. E.g. a problem with blue foreground on white background and white foreground on blue background are the same color set and cannot be submitted twice.

Actual Result

In the actual result field – besides the typical actual result that you have to enter in regular exploratory tests –, provide which checkpoint failed, e.g.:

Failed WCAG 2.1 checkpoint(s): 1.3.2 Level A


What attachment has to be attached depends on the type of accessibility problem:

  • Color contrast: screenshot

  • All other problems: screencast

Screenshots: As in regular tests, the issue must be marked on screenshots.

Screencasts: While recording your screencast, please slow down your actions before you reach the element that has the issue. If you record your actions at normal speed, the viewer will otherwise miss the issue. If you perform actions too fast while recording, the TL might ask you for an improved recording.

Keyboard navigation issues

Your screencast must include what keys you pressed on your keyboard during your recording, otherwise viewers cannot comprehend the issue. Enable the on-screen keyboard on your computer, which is available for both Windows and macOS. A virtual keyboard will overlay part of your screen and you simply click on a button to simulate the corresponding key press.

Form Template

We currently do not have a form for accessibility reports, so meanwhile we use the form for usability reports. In order for all reports to look the same, they have to be formatted. Below, we provide a formatted template that we ask you to use.

Simply copy-paste the template into the single text field of the usability form, replace the placeholders (e.g. <tool>, <URL>, etc.) and enter your information.


  • If you didn't use a tool to find the issue, e.g. for Keyboard Navigation issues, the first step should be as usual: Open <URL>

  • If you need more or fewer steps, simply adjust the numbering accordingly.

##### Steps
1. Using <tool>, open <URL>

##### Actual result
<actual result>
**Failed WCAG 2.1 checkpoint(s)**: X.X.X Level <A/AA>

##### Expected result
<expected result>


Screen reader example


[AA] [2.4.3]: Focus not trapped in hamburger menu modal


  1. Using VoiceOver, open

  2. Swipe right to focus hamburger menu

  3. Double tap to activate it

  4. Swipe through the expanded hamburger menu modal and observe

Actual result:

The focus continues to move through the background content behind the modal, which is not part of the overlaying hamburger menu.

Failed WCAG 2.1 checkpoint(s): 2.4.3 Level AA

Expected result:

The focus should be trapped in hamburger menu modal. Hidden elements from the underlying page should not be focused and announced.

Keyboard navigation example


[AA] [2.4.7] Get Demo link does not have visible focus outline


  1. Using NVDA, open

  2. Press TAB to focus “Get a Demo” button under “Do you take Quality Personally” section and observe

Actual result:

The “Get a Demo” link in the “Do you take Quality Personally” section does not have a focus outline.

Other occurrences: Social Media icons

Failed WCAG 2.1 checkpoint(s): 2.4.7 Level AA

Expected result:

Actionable elements must have visible focus outlines when they are focused.

Color contrast example


[AA] [1.4.3] White text on blue background for “Get a demo” link fails color contrast requirements


  1. Scroll down to “Get A Demo” link

  2. Measure the color contrast ratio of “Get a demo” link

Actual result:

The “Get a Demo” link fails the color contrast requirements. The blue foreground text (#21BEF4) on the white background (#FFFFF) has a contrast ratio of only 2.15:1.

Failed WCAG 2.1 checkpoint(s): 1.4.3 Level AA

Expected result:

Small text should have a contrast ratio of at least 4.5:1. Large text (14 pt bold or 18 pt and larger) should have a contrast ratio of at least 3:1.

Did this answer your question?