Manual Accessibility Testing Complexity
Manual accessibility audits tend to be complex undertakings because the W3C’s Web Content Accessibility Guidelines (WCAG) can be difficult for many to understand and to know how to fully test.
A comprehensive manual audit usually requires testing on multiple devices, including mobile devices. Different operating systems and different assistive technologies are also usually involved. Additionally, testing to WCAG requires understanding how different groups of humans may perceive and access content.
Once an accessibility issue is identified, the issue must then be documented in such a way that those who receive the audit results can understand the issue and how this may relate to poor accessible design or markup on a web page.
If you have been working in digital accessibility for some time, you know that the digital accessibility consulting field has grown over the years. Most of those who have recently become accessibility professionals usually do not have a background in software testing. Why does this matter?
A Critical but Overlooked Skill
At Converge Accessibility, we are often asked to review testing results from other accessibility testing firms or testing results from expert witnesses in accessibility litigation. While most do a pretty good job of identifying accessibility issues, they rarely do a good job of documenting those issues.
In over two decades of working in software testing, I have had to try to break things and then explain how I broke them. My business partner describes this as a marketable form of clumsiness, but he is an attorney, so I wouldn’t expect anything less. I can say that breaking something is the easy part!
I learned and refined my skill set working at Microsoft and eventually ended up in Microsoft’s Accessible Technology Group (ATG). During this time, I discovered that taking extra time to methodically document issues (aka bugs) was vitally important.
In so doing, I follow a repeatable pattern that helps to ensure I provide enough information for anyone who needs to understand, and address the issue, can do so with little to no additional information.
Over the years, I’ve given presentations on this topic at conferences like CSUN and Accessing Higher Ground— and with the growth we are seeing in the accessibility testing field, I think it is time to revisit this topic.
In the coming weeks, I would like to describe my process, give real-life examples comparing good and bad bug reports, and give you all the tools you need for becoming an accessibility issue documenting wiz.
Thanks for reading!!!
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 1”