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 type of problem (and tool):

  • NVDA: <bug title> (screen reader issue found with NVDA)
  • JAWS: <bug title> (screen reader issue found with JAWS)
  • VoiceOver: <bug title> (screen reader issue found with VoiceOver)
  • Talkback: <bug title> (screen reader issue found with Talkback)
  • Color Contrast: <bug title>
  • HTML Validator: <bug title>
  • Keyboard Navigation: <bug title>
  • Video: <bug title>
  • Zoom: <bug title>

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

  • NVDA: 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:

  • NVDA: Sign-out link announced without a role
  • NVDA: Filter toggle button announced with incorrect state
  • NVDA: Page title is not unique and descriptive
  • NVDA: Headings are not properly nested
  • NVDA: Focus outline is not visible for tester link below Sign-in button
  • Color contrast: Blue text on white background for Sign-in button fails color contrast requirements

Steps to reproduce

Screen reader issues: In addition to the call of the test URL, include the name of the screen reader in your first step, so that it e.g. says:

  1. Using NVDA, open <test URL>

Screen reader issues: 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

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>

Color contrast issues: 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 general: If a checkpoint fails for multiple elements of the same type (e.g. button or link), group these occurrences in one report.

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

Actual Result

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

Attachments

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

  • Color contrast: screenshot
  • All other problems: screencast

Examples

Example of a desktop issue

Title:

Keyboard Navigation: Get Demo link does not have visible focus outline

Steps:

  1. Using NVDA, open https://test.io/
  2. Press TAB to focus “Get a Demo” button under “Do you take Quality Personally” section and observe

Expected result:

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

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

Example of a mobile issue

Title:

VoiceOver: Focus not trapped in hamburger menu modal

Steps:

  1. Using VoiceOver, open https://test.io/
  2. Swipe right to focus hamburger menu
  3. Double tap to activate it
  4. Swipe through the expanded hamburger menu modal and observe

Expected result:

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

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

Related articles:

Did this answer your question?