Using accessibility literacy to counter accessibility ignorance
Introduction
In any organization working to make their products and services accessible, there always comes a critical point when the capacity of one or a few accessibility specialists maxes out. I gave a talk in 2019 at A11yTO Conf on the topic of designing accessibility education in response to this exact problem. The solution I proposed then, and still believe in today, is to focus on activities that grow accessibility literacy. Accessibility literacy must be a goal for any kind of sustainable, scalable accessibility program.
In this post, I'm going to expand on the idea of accessibility literacy, why it's important, and ways you can encourage it in your organization.
What is accessibility literacy?
The idea of accessibility literacy builds on information literacy, a concept that comes from library science. Information literacy is a set of skills that allows non-experts to meet their information needs. Being literate in this sense means being able to:
- Recognize when you have an information need
- Find information to potentially meet that need
- Evaluate that the information is accurate and useful for your context
- Use and communicate the information effectively
If we extend this idea of literacy to accessibility, we can begin to identify skills that people need to seek out, evaluate, and use accurate information, to make good decisions about their work.
Teaching accessibility literacy
The primary goal of accessibility literacy is to help people learn to ask the right questions in context, thereby reducing the assumptions they make.
Vocabulary
The first step is teaching vocabulary. This allows people to research accessibility effectively and communicate with their teammates. This includes things like types of assistive technology, what a focus outline is, what the Web Content Accessibility Guidelines (WCAG) include, and the like. It helps address the "people don't read" problem by giving people keywords they can use to search efficiently and quickly assess whether a given resource fits the need.
This type of learning is usually addressed by traditional training workshops and online courses. It benefits everyone in an organization, not just people who work on digital products, since it eases conversation about digital accessibility in general.
This first step gives people a low level of literacy. It's a starting place.
Trust
The next step is helping people vet trustworthy sources. This allows people to do their own research without the direct help of an accessibility specialist, or someone else with more accessibility knowledge.
Trustworthy sources include vendor documentation, Web Accessibility Initiative (WAI) specifications, blog posts, forum posts, GitHub discussions, and social media posts by disabled people and accessibility specialists.
At this stage, people need to learn how to get plugged into the conversations happening every day about accessibility and disabled peoples' lives. They need to understand how to evaluate bias, check dates, interpret recommendations and guidelines, and understand context.
This develops a medium level of literacy. At this stage, people should feel more comfortable participating in discussions about accessibility with their team and making decisions about accessibility in their work.
Nuance
The third step involves understanding nuance in the accessibility space. After someone has a good grasp on how to evaluate resources and back up their decision-making, they may be ready to start leading accessibility discussions in their organization. To do this effectively, people need to be able to grasp the difference between "can" and "should" when it comes to making decisions that impact the accessibility of a product or service.
This is the difference between accessibility as usability and accessibility as compliance, where a compliant product may pass automated and manual testing with flying colors but fall short for actual disabled users.
A person with high accessibility literacy knows accessibility is complicated, but not impossible.
I think the idea of accessibility literacy can be extended beyond just information seeking, however, to bump up against another related topic: ableism.
Accessibility ignorance and ableism
Accessibility ignorance actually goes beyond just a lack of accessibility literacy. Accessibility ignorance is a facet of ableism, since it causes people to make decisions that actively harm disabled people.
- Accessibility ignorance isn't usually malicious.
- It's assuming that accessibility is taken care of because your organization has an accessibility specialist on staff, or has accessibility "baked in" to a design system.
- It's providing accessibility training for only teams that build products and not people that work in support, legal, operations, leadership, or other parts of the organization.
- It's expecting accessibility work to happen without impacting schedules and roadmaps that didn't originally take accessibility work into account.
- It's assuming disabled people don't use your product.
- It's not hiring disabled people.
- It's hiring disabled people but only to do accessibility work.
- It's not including disability in your organization's diversity and inclusion work.
- It's viewing accessibility as being in competition with security, privacy, localization, or "shipping fast."
- It's doing accessibility testing, but only right before a launch, where no real change can be made.
- It's compartmentalizing accessibility work as only a development problem, or as only a UX problem.
- It's not addressing your own individual, often-internalized ableism.
I highly recommend EJ Mason's talk on the subject of ableism in accessibility work, Accessibility Is a Hydra.
Cultivating accessibility literacy
So, how do we build accessibility literacy at the organizational level? This takes at least two different kinds of initiatives: It requires education, but it also requires buy-in from the larger organization.
Team education
The type of accessibility education that works best for a team will depend entirely on the culture of the organization, the needs of the team, and the learning styles of the team members. However, there are a variety of learning opportunities that I've found success with in the past.
"Just in time" documentation
"Just in time" documentation might take the form of having accessibility docs and features built into your design system, handbook, or other content that's shared by the team. This type of content works best when it's with all of the other learning materials, not in a separate accessibility silo. Including detailed recommendations or guidance for your specific environment and toolset means that people can do accessibility work even if they don't know all the ins and outs of why they're doing it or how.
Teaching with the product itself
A great way to learn in context is to learn about accessibility issues that have appeared in a product in the past, experiencing user research, or pairing with an accessibility specialist during a regular work cycle or sprint. This can take the form of looking at issue tickets, perhaps in a mentoring session, talking through a current design problem, or sitting in on a usability session with a disabled user. This makes accessibility work more tangible, and helps teams focus on addressing actual issues, rather than frittering away at possible scenarios.
Create a guild
The purpose of an accessibility guild or network shouldn't be to review accessibility concerns for the product, thus creating a bottleneck. Instead, a guild should help individuals find allies, mentors, mentees, and get feedback on problems they are trying to solve. The goal of a guild should be to connect people from different parts of the organization with each other. A guild is especially crucial at a very large organization, where there may be many teams working on separate products.
Organization buy-in
In addition to education and support for people who are doing accessibility work, there are also a few things that need to happen at the organizational level. Without that organization-wide buy-in and support from senior leadership, specialists will burn out, and literacy won't flourish.
- Get actual buy-in from product management and senior leadership. Make learning the basics required, and not just for product teams. Work with a specialist to create a roadmap to ramp up the whole organization in their literacy, and a roadmap to make your product more accessible. Make accessibility tooling and workflows part of the default.
- Normalize having disabled people in your organization. Don't hire disabled people just to do accessibility work. Ensure that internal tools are accessible. If your diversity and inclusion efforts don't already include disability, change that. If you have employee resource groups (ERGs) and none of them are for disabled employees, change that. Lean on your organization's existing values to include accessibility, disabled employees, and disabled users.
- Create benchmarks or objectives and key results (OKRs) around accessibility. If your organization is driven by quantitative data, use that strength to establish and capture measurable goals around accessibility. These might, initially, measure a baseline like how many teams are running automated accessibility testing on pull requests. For a longer term goal that moves beyond compliance, you might track scores on the Accessibility Usability Scale (AUS). Celebrate teams that fully participate in these initiatives, and explore ways to better support teams that are struggling.
Think about all of this as setting up accessibility operations, much like you may already have dev ops or UX ops. Choosing to do accessibility right means establishing a organization-wide commitment to making both the organization and the product more accessible, as well as giving specialists the tools and support they need to get that work done without risking burnout.
Accessibility literacy is one way to help take the weight off of one person's shoulders and put it where it should be, across the shoulders of everyone in the organization. The lift should be lighter, and infinitely long.