Summary: Accessibility seems to struggle between Technical Accessibility vs Inclusive Design. But by seeing accessibility as a technical task, namely optimizing browser code and Web elements, you miss essential quality benchmarks. Worse, you ignore the wider Inclusive Design innovation opportunities and organizational inclusion maturity– an imperative. So it’s essential to understand that accessibility requires more than just technical effort.
It’s essential to define and manage Accessibility efforts correctly. In this post, I’ll dig into everything you need to know.
First a comment about former founder of NNGroup, Jakob Nielsen, (the guru who gave us 5 user tests) who now writes excitedly about AI’s future. In musing about how he thinks AI replaces the need for current accessibility efforts, he rubbed the accessibility community the wrong way. In his prophecy, he casts accessibility as a defeat (and dead-end goal) to be replaced by custom AI-tailored disability experiences. For purposes of this post, his ‘pure technology will save us’ from the accessibility problem is in fact, part of the problem I outline below.
Technical Accessibility vs Inclusive Design
To begin with, there’s a big problem with how the industry sees accessibility. It stems from a legacy perception of accessibility being a software engineering task. Only in the last 5 years has this perception been forced to change. Yes, accessibility work does involve fixing and setting up standards-compliant code, but there’s more.
Accessibility is also a UX team’s work. This includes a UX Researcher, UX Designer or Accessibility Designer and an Accessibility Specialist.
UX Researchers: Conduct user testing or Accessibility testing with users with disabilities. They conduct ethnographic studies for accessibility to explore the Problem Space and understand how design strategy can accommodate Inclusion Innovation.
Designers: Layout screens for optimum access. Informed by User Research, they bring insights to design decisions that accomodate and empower users wtih disabilities– before developers optimize the browser or app code.
Accessibility Specialists: Advocate for users with disabilities, called “Disability Advocacy” by sharing lived expereinces, providing context around decisions and by testing and re-testing (QAing). Since automation can only take you so far…
See, You need 3 types of user advocacy…
Many organizations approach accessibility anemically with a dev team and then use internal employees or borrow from the Employee Resource Groups (ERG’s). This is not a strategy. It’s fundamentally broken…
Inclusion is more comprehensive than most stakeholders think
The good news is that Accessibility has evolved from merely a technical requirement to an integral part of fostering equity and inclusivity. Industry leaders such as Microsoft and Adobe even call their accessibility efforts “Inclusive Design”. By this definition, the focus is on users with disabilities or digital accessibility.
But others, like Google and Airbnb, expand their definition of inclusion to cover accessibility + other blockers to access from marginalized identities. The reason? It’s due to something called “double discrimination”. If you are blind, black, and female, you are twice or 3x as likely to be left out. So it’s crucial that when we define or use the term Inclusive Design, we are not just meaning disability- as vital as that is.
Why are UX teams not core to Accessibility efforts?
The technical definition has dominated accessibility conversations because, like many design efforts, the focus is on working code, not user scenarios that matter most. Working and optimizing code has an engineering bias: UX and accessibility work can be seen as non-essential when racing to meet WCAG guidelines.
As for including users with disabilities? Well, forget that (insert excuse here- too expensive, too many disability types, hard to find them etc, etc). Or more recently (shamefully) wait for generative AI to replace their participation since it will know precisely what they need.
On top of that: UX designers and researchers have for years been under-exposed and thereby under-skilled in doing accessibility work and disability advocacy specifically. The UX field is just starting to catch up, but accessibility has recently come of age. Microsoft, Google, and Apple (in that order of industry noise) have, in the past few years, evangelized a disability-centric approach.
So accessibility is a team approach that requires systems, processes, user research, and operational efficiency. Do we need AccessOps?
The idea of AccessOps suggests that in addition to operationalizing our UX work via DesignOps and ResearchOps, we also need an operational focus for accessibility. -Frank Spillers
So how to manage this situation?
First, disability should not be swept up with the broader definition of Inclusive Design above. When you build equity for users with disabilities, make sure it’s about them. That means conducting User Research with people with disabilities. One way to keep it aligned to diversity as default is to recruit intersectionally. That means disability plus a balance of race, gender, sexual orientation, etc. But make sure disability is your driver. If you’re doing an inclusion project where race is your driver, flip it. Race + disability as your secondary intersectional insight point.
Next, build accessibility or inclusion maturity. This means you manage Inclusive Design and Accessibility as a program. Everyone is working strategically toward the goal. That means policy, process, and internal decisions reflect inclusive design practices, in the case of disability, accessibility testing with users (with disabilities).
More than automation: Leaving users out is the biggest problem in accessibility work. It also shows weak accessibility or inclusion maturity. The idea you can automate ‘the access problem’ is not feasible; nor human-centered. AI-based accessibility tools are currently about 10-15% effective. By their admission (studies), industry-leading tools like Deque have a 57% success rate. According to a 2022 press release, machine learning, and semi-automated testing push that to 80%.
Generative AI for accessibility has potential to move accessibility forward, but it’s not default yet. In the best scenario it can help reduce the technical effort involved in today’s accessibility, allowing for designers to great more equitable solutions earlier on: solving for the “right problem” for people with disabilities.
There is a place for automation: developers must run scripts and leverage tools. However, a classic mistake with accessibility is making an end product accessible without considering whether it has been conceived with equity in mind. Equitable design- the goal of Inclusive Design- means offering the most empowering formats, layouts, and content positioning. It’s about advancing your accessibility toward equity and quality– not just compliance with standards.
Why this matters: According to the Centre for Inclusive Design, “the relative cost of retrofitting a product or service to become inclusive will increase significantly over time and can reach up to 10,000 times the cost of making it inclusive by design.”
Accessibility is not a checkbox item: “We’re compliant, done!”. It’s about bringing users with disabilities into the conversation so designers can think about and design for accessibility early on, saving developers the optimization hurdles they usually go through. The “cost of accessibility” like SEO or UX is because it is not done early on or defaulted in product development team workflows.
Call to action
While technical accessibility is indispensable, viewing it solely as a developer’s responsibility is limiting. When organizations approach accessibility from a technical standpoint, they risk neglecting the more significant strategic implications of inclusive design.
What we have found works: Using a triangulation approach to your accessibility can help. This uses a balance of checker tools, automation, WCAG guidelines, and involvement of users with disabilities.
Upcoming Classes:
- Learn how to prioritize Inclusive Design: Join this Designing for Accessibility First Masterclass
- User Research Intensive– learn user research working with neurodiverse users (fee goes directly to users)
