Accessibility tool helping IT teams and clients understand user challenges with inaccessible designs.
UX Strategy | User Research | Prototyping
Features
Gamified accessibility challenges with tasks to complete and mini recaps: color blindness filters, light sensitivity, magnification, screen reader view, or try keyboard navigation
Accessibility violation details
Digestible accessibility summary for clients
Role
UX Designer collaborating with 3 UX Designers and 1 UX Researcher
Duration
2 months
Business Context
The IBM Accessibility team enables the rest of IBM to create digital products that are usable by all individuals. They have outdated demo websites that do not reflect modern websites and therefore do not showcase the value of the IBM Accessibility Checker.
The objectives were:
Create an open and public digital experience that is current and can demonstrate the value of accessibility as it pertains to universal experiences
Highlight the MVP Design items that need to be considered for accessibility
Demonstrate the value of the IBM Accessibility checker and IBM's Equal Access Toolkit.
How might we show off the IBM Accessibility Checker in a way that appeals to potential users in a glance?
Define goals and conduct user interviews
First we questioned and delved deeper into what exactly is the IBM Accessibility Checker? Then we asked how IBM is currently showcasing the checker? Next we asked ourselves what exactly appeals to users? What do they need? And who are our users? These questions and many like it strongly based our research methodologies.
Research Summary
Phase 1: What is the current state of accessibility?
7 Sponsor Users (“Accessibility Advocates”)=
2 developers + 5 marketers
Phase 2: What is the experience of typical developers?
6 More Developers= 3 “average” developers + 3 “advocate” developers
Phase 3: What are the current pain-points?
2 Advocate developers + 2 marketers
Analyzing data via user personas
Before we began our user interviews we created our empathy maps based on our assumptions of our two original users, which were the developers and marketers. We decided to create an As-Is Scenario that helped us understand where best to focus our attention in the journey. It also indicated where we need to gather more information.
As a result of using this exercise, we discovered that the average developer experienced several pain points creating a negative feedback loop in their workflow when trying to implement accessibility standards.
Research findings
After we felt solid in our user research, we started to consolidate our quotes and insights and convert them into design goals that include need statements and success criteria for each persona.

Insights
Lack of incentives, not lack of interest, inhibits developers from learning about and implementing accessibility.
Accessibility errors come from not knowing what it’s like to use assistive technology.
Existing tools do not simulate the experiences of using assistive technology well enough.
Design Goals
What do developers need?: Developers and clients need a way to understand what it’s like to use assistive technology so they can empathize with users & understand how they can build experiences that are accessible to everyone.
How do we know we solved the problem?: Developers can visualize the impact of accessibility features on their digital products so they can implement accessibility earlier in their workflow.

Insights
Empathy is built through experience.
Marketers often talk to high level executives who are more interested in high level overviews.
Design Goals
What do marketers need?: Marketers need a way to help clients understand the importance of accessibility so they can implement accessible design on their products & develop a culture of accessibility in their org.
How do we know we solved the problem?: Marketers can communicate the impact of accessibility, inspiring clients to engage IBM to help them maximize resources and reduce legal risks, extend market reach, and ensure product longevity.
Brainstorming how to address user needs
My prototype
After finishing up our needs statements and hills, as a team we started ideating. Therefore as a team, we decided to create our own prototypes and come back together to talk about them.
After realizing that some of our ideas were similar to each other we split into 2 groups, based on similarity. Another UX designer and I grouped together based on our gamification concept, while the rest grouped together based on the demonstration of the checker.
Gamification concept
Defined features
After each of our concepts were solidified into one idea we created our Developer and Marketer To-Be Scenarios which detailed the future user journey with our implemented solutions.
Result: Showing the value of the IBM Accessibility checker through a game experience.
The requirements are:
Redesigned site
Help users experience using assistive technology
Simplify checker results for clients
Promote IBM Accessibility Checker to potential users
Alex and Andie get to experience how a seemingly simple task like checking their bank account can take much longer than it needs to because the site is inaccessible.

Understand the impact of the inaccessibility in their present workflow
Look at what each violation entails and why its an issue
Look at additional resources they can press fixed selected issues to see what it would

Andie- Marketer
Better push why accessible design is important
Send a more digestible information summary to their clients
Push for their clients to cultivate more of an accessible culture within their company
After we completed the to-be scenarios, we all worked to create the prototype. I sketched the game experience, created the UX strategy for the accessibility views, prototyped the game recap page and the entire screenreader flow using Figma.
Clearly defined UX strategy to impact
Next, I created a rough sketch of the finalized game experience. Then, I created tables for the three views to showcase the clear correlation between the different use cases, technical problems, and results. This helped direct everyone's attention so they could understand the intersections of the designs ad what they should be presenting for each view.
My rough sketch
UX strategy to map accessibility impact
Iterations and Screenreader View
Game Recap- Mid-fidelity wireframe
Game Recap- Hi-fidelity wireframe
Screen reader View
Furthermore, for the screenreader views I started by doing something similar to the table before in dividing the sections by accessibility status, the specific issue being resolved, and website visibility resulting in prototyping 16 screens.
By creating this user flow, I simulated the experience of using a screen reader for developers and marketers' clients so they can start to empathize with their end users.
Prototype video
Final User Journey
The game experience is driven by a side bar on the right that would include information about the challenge and the list of items they need to complete. Next after each challenge a mini recap would appear. In the very last challenge the user would be prompted to enter their own website to check for inaccessibility and how to fix it. Then final recap game page would encapsulate the summaries of all 3 web experiences the user experienced. It would also tell them what lessons they learned and the resources they can access.
Impact
With the newly designed site Alex and Andie's clients can use different assistive technology to get a glimpse of how people with different disabilities navigate an everyday site. They can use different color blindness filters, light sensitivity, magnification, screen reader view, or try keyboard navigation.
With our solutions, developers and clients are able to experience how users feel navigating 🗺 inaccessible websites.
More specifically developers are more knowledgeable 🧠 about resolving accessibility coding issues 💻 and clients are more empathetic ❤️ to their end-user.