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 type of problem and accessibility level (A or AA):
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:
Screen Reader: 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] Screen Reader: Sign-out link announced without a role
[A] Screen Reader: Filter toggle button announced with incorrect state
[A] Screen Reader: Page title is not unique and descriptive
[A] Screen Reader: Headings are not properly nested
[AA] Keyboard Navigation: Focus outline is not visible for tester link below Sign-in button
[AA] Color Contrast: Blue text on white background for Sign-in button fails color contrast requirements
Steps to reproduce
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 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):
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.
In the actual result field – besides the typical actual result that you have to enter in regular exploratory tests –, provide the following additional information:
- What checkpoint failed, e.g.
Failed WCAG 2.1 checkpoint(s): 1.3.2 Level A
- Suggested resolution (if known to you)
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.
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.
1. Using <tool>, open <URL>
##### Actual result
**Failed WCAG 2.1 checkpoint(s)**: X.X.X Level <A/AA>
**Suggested resolution**: <optional>
##### Expected result
Screen reader example
[AA] Screen Reader: Focus not trapped in hamburger menu modal
- 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
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
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] Keyboard Navigation: Get Demo link does not have visible focus outline
- Using NVDA, open https://test.io/
- Press TAB to focus “Get a Demo” button under “Do you take Quality Personally” section and observe
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
Actionable elements must have visible focus outlines when they are focused.
Color contrast example
[AA] Color Contrast: White text on blue background for “Get a demo” link fails color contrast requirements
- Open https://test.io/
- Scroll down to “Get A Demo” link
- Measure the color contrast ratio of “Get a demo” link
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): 2.4.3 Level AA
Suggested resolution: The foreground text color could be changed to #087EA6 to increase the color contrast between the foreground and background colors.
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.