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.
Title
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 |
|
|
|
|
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:
Using <tool>, open <test URL>, so e.g.Using NVDA, open https://www.test.io
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 AccountPress the ENTER key to activate Sign out linkSwipe 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):
Open <test URL>...
...
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
Attachments
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.
Notes:
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>
2.
3.
4.
5.
##### Actual result
<actual result>
**Failed WCAG 2.1 checkpoint(s)**: X.X.X Level <A/AA>
##### Expected result
<expected result>
Examples
Screen reader example
Title:
[AA] [2.4.3]: Focus not trapped in hamburger menu modal
Steps:
Using VoiceOver, open https://test.io/
Swipe right to focus hamburger menu
Double tap to activate it
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
Title:
[AA] [2.4.7] Get Demo link does not have visible focus outline
Steps:
Using NVDA, open https://test.io/
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
Title:
[AA] [1.4.3] White text on blue background for “Get a demo” link fails color contrast requirements
Steps:
Open https://test.io/
Scroll down to “Get A Demo” link
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.