What I Learned by Doing an Accessibility Audit for the First Time
Part 1: Background and "Why Accessibility?"
Recently in my day job at IBM, I had the opportunity to conduct a formal accessibility audit on a product for the first time in my professional career. This was a pivotal moment for me. I'm not going into depth within this blog post about why accessibility is so important- but, I do think it's important to share my personal experience with it.
For me, growing up in a household with a disabled father, an aging grandparent, and a chronically ill brother was the start of my interest in designing accessible experiences. My own experience with Visual Snow Syndrome also increased my desire to help teams build more accessible products. When I was first seeking a diagnosis after the onset of Visual Snow, I relied heavily on assistive technologies like Freedom Scientific's ZoomText screen magnifier. While nowadays I'm able to work effectively despite it as I can largely ignore/"look past" most of the symptoms, I have large floaters in both eyes that still make completing certain visual perception or reading tasks at a given time challenging.
It's hard for me to explain the value of accessibility well since it seems obvious to me from my experiences, but if I had to put it simply:
At some point in time, everyone will face having a disability (temporary, situational, permanent, or as a result of aging). Why not design as many things as possible such that they are able to be used by anyone, regardless of ability?
With all that in mind, I was excited to conduct my first accessibility audit and help improve our software for all users.
Part 2: Starting and Conducting the Audit
Prior to starting the audit, I took two accessibility certification courses through IBM to ensure that I understood the basics. Even after that, getting started on the audit may have been one of the most challenging parts. First, I combed through the IBM Accessibility Requirements list, which is a compiled list of accessibility standards that IBM products must comply with. After reviewing all the standards for my own understanding, I compiled them into a template for myself to use. Here's an example:
- Type of Standard
- Source of Standard: Standard #, Standard Name
- Brief Description of Standard
- Part of Product: Notes on how meets/doesn't meet standard
- **Question About Standard
So, for example:
- WCAG 2.1: 1.1.1, Non-Text Content
- All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
- Home Page: Missing alt text for images
- **Does this apply to photos?
After getting my note taking document set up with the above template for each standard, it was time to start the audit. I did the audit in several passes. For example, I did one pass with a screenreader, one with an accessibility checker plug-in, one visually by myself, etc., and filled the note taking template out as I went.
It was greatly beneficial to me, as someone who had never done an audit before, that I was able to ask questions to the wider IBM accessibility community about standards and requirements as I went. My manager also has a background in accessibility and has done these audits regularly, so he was another incredibly valuable resource for me. If you don't have someone you know who is an accessibility expert, I'd recommend reaching out to one of the many groups online that focus on this important work.
I made slow yet steady progress on the audit and did frequent reviews of my work with my manager to check for accuracy. Eventually, I created a full report for the product team, which included areas that did not pass the audit and my design recommendations to address those areas.
Part 3: What I Learned
There were several things I learned though the process of conducting my first accessibility audit:
1. It's hard when you haven't done an audit before, but the resources are out there and the process will get easier the more you learn the standards. Like most things, practice makes perfect. The more that one can strive to understand the standards and recognize when something doesn't pass a standard, the easier the audit becomes.
2. I gained empathy for screenreader users and came to understand how a design or development error- a broken link, an aria tag that doesn't read something correctly, a graphic that has no alt tag, etc- can completely break an entire experience for a user. This was easily my biggest takeaway from the entire audit. When someone relies on an assistive technology to do their work, live their life, or even just browse the web like a sighted person can, running into something that doesn't work or is inoperable is at best, an annoyance, and at worst, dehumanizing.
3. Although I knew this to some extent before conducting the audit, accessible design IS, by nature, good design. The improvements in accessibility that our team's designer is making also improves the experience for sighted users- it's more cohesive, understandable, and parsable. Not to mention that it's my belief that within design, function should take precedence to visual beauty every time. If not everyone can use your product, it doesn't matter how beautiful it is.
I've learned a lot about accessibility and about design through this exercise. I recommend every UX professional give it a try- you may be surprised by what you learn!