How to Document Accessibility Issues – Part 2

Get Noticed

This is part 2 of the series on How to Document Accessibility Issues. As mentioned in part 1, documenting accessibility issues is a critical, but often overlooked skill. While documenting issues is not ‘fun’ and can also be time consuming, doing so correctly the first time not only saves time later but also helps ensure that the issue will be addressed instead of ignored.

There are two types of reporting for accessibility issues we are going to address:

  1. End User Reports
  2. Accessibility Tester Reports

We will first cover how end users can submit accessibility issues that will be noticed and will have a greater likelihood of being fixed.

End User Reports

End users of a product can have a big influence on how the user experience or function of a website is developed. When it comes to accessibility issues, feedback from end users is even more important because accessibility is often overlooked or relegated to a lower priority. This can be for several reasons but one of the most common is that the web team creating and maintaining the website may have little to no knowledge of accessibility best practices and guidelines.

Knowing how to submit accessibility issues empowers end users with disabilities because it enables them to communicate their needs in the language that developers understand. Doing so also ensures that issues they submit have a greater chance of being taken seriously and being addressed.

While it is not expected that an end user would be proficient at documenting an accessibility issue, knowing what to include will help those on the receiving end better understand the issue and fix it. Here is the basic information to include:

  • Description – A brief overview of the issue
  • Impact – Describe how the issue affects you personally
  • Details – Include the technical details needed to help the web team address the issue
  • Repro Steps – Outline the steps reproduce the issue
  • Results – Describe what happens
  • Expected – Explain the expected behavior

Using the above information, here is an example of what this might look like when submitting an issue. In this situation, the user is attempting to select an article of clothing from an online store but is unable to determine which size has been selected.


Description:

I am unable to determine which size is selected to complete my purchase.

Impact:

This is preventing me from making a purchase of XYZ because I am a screen reader user and cannot see the screen to know which size I am selecting.

Details:

I am using the Chrome browser on a Windows 10 Home operating system along with the NVDA screen reader which I use to access websites as a blind user.
The NVDA screen reader can be downloaded for free at https://www.nvaccess.org/download/.

Repro Steps:

  1. Start NVDA.
  2. Open the Chrome browser and go to https://shopxyz.com
  3. Use the down arrow key to move into the web page. When you hear NVDA announced, “XYZ”, press the Enter key.
  4. Use the down arrow key to move to the size selections that appear right after the header that says, “Select a Size”, and listen for what NVDA announces for each size option. 

Results:

NVDA announces “button” for each selection.

Expected:

NVDA should announced how many buttons (or choices) are available, what size the button represents, and should also tell me which button is currently selected.


Using the above approach should provide enough information to help someone understand the issue being reported along with enough details to reproduce the issue.

Note that the exact steps to reproduce the issue are provided. This is important, especially if assistive technology is involved, because the person or persons receiving this report will likely have no idea how to use assistive technology.

Also notice that the environment where this issue is happening is included. This is critical to reproduce the issue because often an issue that appears in one configuration may not appear in another.

The information provided does not need to be super detailed but should be detailed enough and top the point to help provide a clear understanding.

End User Benefits

Along with having a voice to help support the creation and maintaining of accessible content, end users that use this method of reporting issues can benefit by:

  • The issues that are reported will get looked it seriously
  • May be invited to partake in focus groups and beta testing programs
  • Gives experience as an “tester” for future employment opportunities

Next Time

In our next post on this topic, we will go into what a professional accessibility tester should include in issues they document and the benefits they may experience by doing so.

Infuse Accessibility into Your Existing Process

If you are ready to incorporate accessibility into your web content development lifecycle, please give us a chance to introduce you to WebAlign. The one-of-a-kind accessibility compliance resource on the market today that is flexible enough to fit into your process with minimal effort.

Want to See More Content Like This?

Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!

We're Here to Help When You're Ready

Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.

0 comments on “How to Document Accessibility Issues – Part 2

Leave a Reply

Your email address will not be published. Required fields are marked *

Click to access the login or register cheese