Accessibility Audit & Standardization
Overview
This initiative started in 2019 with feedback we received from a customer who was unable to complete a survey we sent them. She sent us a narrated screen recording attempting to fill out the survey using a screen reader to navigate. Needless to say, our product did not serve her well. After reaching back out to her, we started down the path of what is now one of our core principles--designing with accessibility and inclusive in mind.
This project led to what became one of my passions at Blizzard. I’ve continued to learn how to design inclusively, partnered with various other roles to level them up, and became the subject matter expert of this topic within my department.
My Role & Responsibilities
User research, competitive analysis, heuristic review, surveying, usability testing, information architecture, prototyping, and interaction design.
Outcomes
Primary sections of the Blizzard support website are fully compliant with AA web content accessibility standards.
Commitment from department to be fully compliant across the entire website by 2022.
Established baseline for all future features and components to be built fully compliant moving forward.
Identifying the Problem
A customer of ours called out that our post-contact survey only allowed her to select a subset of the possible responses for each question. We quickly remedied this specific problem, but we knew additional content hadn’t gone through the steps required to be accessible.
Building Empathy and Making a Case for Accessibility
I reached out to someone in Blizzard’s user research department that I had heard was starting to focus on this very topic. Partnering with them, I started down the path of understanding:
Requirements for designing with accessibility and inclusive in mind.
Potential legal implications of not pursuing this.
Stats for how many people who have varying degrees of disabilities and the potential gains for building our products with them in mind.
This translated into a pitch I gave to our product manager and leadership team to make a case for why we needed to make this a priority. After explaining what accessible design is, how it can affect the business, the benefits to our customers, and how I wanted to start addressing these problems, I had unanimous buy-in to pursue this effort.
Microsoft’s inclusive design guidelines emphasized the types of impairments and how everyone experiences them at some point.
Taking the time to listen to our community, it was clear we had room to improve and potentially huge gains from doing so.
Knowing How to Design for Inclusivity
I took the time to start learning how some of the more common assistive technologies work. Experiencing these tools first-hand only emphasized how much work we had in front of us—many features and components were completely inaccessible.
Leveraging the Web Content Accessibility Guidelines 2.1, I built up a strong understanding of what was absolutely necessary to address and how we might improve our product beyond simple AA compliance. While intended for websites, the WCAG success criteria can be applied to all types of interactive mediums
I wanted to experience how someone who might have limited vision and using a screen reader would attempt to complete tasks with our product.
Auditing Our Product
I meticulously documented every issue I found based on a mix of manual and automated testing across the primary sections of our product. The final output was a document that covered engineering and design focused compliance issues, along with suggestions on how to fulfill the success criteria for fixing them. Beyond compliance, I called out areas that we should prioritize immediately after to improve the experience above and beyond compliance.
Designing & Building for Accessibility Moving Forward
The resulting work built up the team’s muscles for designing, engineering, and QAing for accessibility. I knew this was something that had to continue being championed, or it risked getting d prioritized. This led me to create sharable cheat sheets on what factors to account for during each step of the product development life cycle. Designers are tasked with building the necessary affordances in from the component level, engineers are writing code with programmatic solutions, and QA is catching any misses that then get resolved before launch.
In 2020, the blizzard website has had every new feature built with accessibility in mind, and we now have a department goal of retroactively going back to update old feature work for AA web content accessibility compliance by 2022.
Example of how design delivers documentation that accounts for all accessibility needs from the UI component level. This ensures users will be able to use this feature wherever it’s used.