IBM Awesome Access
Changing the way web accessibility is handled at the start.
Overview
My Role
Patterns UX Design Intern. End-to-end involvement with a particular focus on visual and interaction design
Timeline
6 weeks in the Summer of 2021
The Problem
The IBM Accessibility team needs an updated tool to showcase the abilities of the IBM Accessibility Checker.
Tools/Skills
Surveying, competitive analyses, user interviews, ideation, prototyping (interaction and information architecture), usability testing, Figma
Team
KT Son, Ramse Dickey, Brandi Nichols, Adeola Kukoyi, Tim Wei (Our Coach!),
and myself!
The Solution
A web experience that recreated the existing IBM accessibility demo site to help executives and IBM developers better understand the importance of accessibility through the facilitation of empathy.
Problem Background
IBM Accessibility provides guidance and tools such as the Equal Access Toolkit that provides detailed guidance on how designers, developers, and more can increase their products' accessibility.
Within the Equal Access Toolkit is the Accessibility Checker, a Chrome extensionthat detects accessibility issues for web pages and applications.
IBM currently has a site, Altoro Mutual, used to showcase the Checker yet the team feels outdated and users can't relate to the site.
How might we show off the IBM Accessibility Checker in a way that appeals to potential users at a glance?
Research
We started this project by conducting secondary and primary research on the topic of the Accessibility Checker. We conducted 17 interviews on 12 users, conducted 3 competitive analyses, and participated in IBM's iX Empathy Lab.
Lack of Incentives
Lack of incentives, not lack of interest, inhibits developers' from learning about and implementing accessibility. They just want to get the job done fast.
Unawareness
Accessibility errors come from not knowing what it's like to use assistive technology.
Simulating Assistive Tech
Existing tools do not simulate the experiences of using assistive technology well enough.
Empathy
Empathy is built through experience.
Side Note
After several interviews, we discovered that our sponsor developers were very knowledgeable about accessibility and had limited experience with the Accessibility Checker. After this discovery we decided to pivot and found IBM developers with average knowledge of web accessibility to interview.
Research Takeaways
After summarizing everything that we learned from our research, we defined needs statements for our two user types and created personas.
Marketers
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 organization.
Developers
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.
Andie
- Faces middle-management level clients
- Promotes the use of the Checker & IBM accessibility services
Alex
- An "average developer" not well versed in accessibility
- Wants to develop for accessibility, but prioritizes timeline
Ideation
After developing our personas and their needs, myself and my four other teammates came up with different design ideas that addressed the problem and related back to our research findings. We then grouped them together to come up with two separate concepts, which we then presented to our stakeholders and grouped them together to make our final product.
Lo-Fi
Multi-View Demo Site
This concept combined my sketches with KT's which introduced the idea of a reverse accessibility overlay with a hard coded example site to show the capabilities of the Accessibility Checker.
Educational Game
This concept combined Ramse's and Brandi's ideas which was an amalgamation of a gamified demo experience with a walkthrough explanation of the Accessibility Checker.
Evaluation
Developer Input
We met with a few IBM developers who were knowledgable with web accessibility standards to discover impactful accessibility issues to address in our product.
From here we were able to address the follow issues in our product:
Vision View
- Color contrast
- Image of text
- Reliance on color to convey meaning
- Referring to page content by position
Screen Reader View
- Missing alt text
- Inconsistent / illogical heading levels
- Bad link text
- Static error feedback
Keyboard Navigation View
- Weak / nonexistent focus indicator
- Mouse operable components not reachable through keyboard
- Illogical tab order
- Modal (no keyboard trap)
Design Rationale
Many of the design decisions we made were based on usability testing and our collective brainstorming of workflows.
Higher Contrast
We originally were planning to use the light mode designs from IBM's Carbon design system. However, our stakeholders and usability testers noted that they needed there to be a clear separation between the Altoro Mutual site and the sidebar.
The question on whether or not to use Carbon on the Altoro Mutual site was also a consideration. We chose not to so there wouldn't be any confusion as to why an IBM product was inaccessible.
Reverse Accessibility Overlay
Our original idea of an actual overlay didn't make sense because:
- Toggles often provide instant responses
- We wanted to provide users with
more context
- The ability to close the overlay wouldn't allow users to learn from the site
We did not go through with this design and instead incoporated checkboxes and context into the sidebar so we could resolve the issues listed above.
Enabling Personal Choice
With our original idea, when users were interacting with the screen reader view they weren't able to see the Altoro Mutual screen. After speaking with the accessibility team we learned that forcing users to simulate assistive technology is problematic. We instead moved forward with allowing users to toggle a switch if they would like to view the screen while interacting with it.
Final Screens
The final wireframes for our project can be found here.
** Please note: These wireframes represent the visual layout of the final product and does not include every intended interaction. IBM developers have information on the interactions and are currently developing it to support the IBM Accessibility team! **
Features
Download Checker
Provides a direct demo of IBM Accessibility Checker on the updated site
Build Empathy - By Choice
Allows users to choose to experience assistive technology, avoiding problematic involvement
Learn About Accessible Design
Provides context to various views and accessibility violations
Experience Through Immersion
Complete a timed task using keyboard navigation to understand other experiences
Components and Interactions
Provides context in to accessible
components and interactions
Lessons Learned
Web accessibility is more important than people realize
This was something that my team realized after the IBM iX Empathy Lab. We were able to understand how people using assistive technology could (or sometimes couldn't!) navigate the web.
Accessibility needs attention from the very start of every project
Many of the developers we spoke with said that accessibility was usually only considered at the very end of a project. This made accessibility seem like a chore which could be prevented by implementing it sooner.
What I'd Do Differently
Actual prototype testing
If I had more time with this project I would like to have an actual prototype built out so we could test out the screenreader and keyboard navigation views without providing an explanation of them to testers.
Additional Views
Providing space for other experiences that people may have with assistive technology would be a big goal. This would be something like providing additional views representing people with cognitive disabilities.