Summary: Doing Web and Mobile Accessibility requires that you take a proactive approach, using good UX research and design methods. Anything short of that will undermine or fall short in delivering not just a good experience to your users with disabilities, but also leaving you vulnerable to ongoing violations of Accessibility legislation.
Tackling Accessibility Starts with Changing How you Think about it
Like many companies lately, Domino’s pizza was sued by a blind man who could not access the company's website. The blind man won and Domino's appealed. Domino's appeal logic reveals a lot about why Web Accessibility does not get done, or get done right. The pizza chain said companies don’t have to make their websites and apps fully accessible as long as disabled customers have other ways to get the same goods and services, such as a telephone hotline. Ouch.
The ADA “does not demand full accessibility for each and every means of accessing the goods or services a public accommodation provides to the public,” the company argued in its appeal. What matters is the “combined means of access to those goods or services,” Domino’s said. Bloomberg (October 7, 2019)
Domino’s appeal was over-ruled by the US Supreme Court. This ruling provides not only a wake-up call, but also an opportunity to reset such long-held attitudes that won’t hold court moving forward.
It’s time to ditch the ‘Accomodations’ Mentality
Many organizations are in a similar place as the popular pizza chain, Domino’s with regard to Accessibility. The assumption is that by taking a reactive and “minimal interpretation” of access can help meet the requirements dictated by laws, guidelines and standards. This view is part of the ‘accomodations‘”’ mentality that is a standard approach, to meeting disability rights first enforced in the US in the late 1980's.
‘Accomodations’ says, this person (patron, citizen, student, employee, user) has a disability and therefore needs to be accomodated. It’s a fair intention at face value. The problem is that it is often used to deliver a side-lined service experience. Organizations and individuals who are (or often take) responsibility for ‘Accomodations’ end up viewing it as a legal obligation task to be fulfilled. In many cases the ‘Accomodation’ doesn’t help or improve the access experience, but provides a legal check box.
The ‘Accomodations’ mentality developed out of the delivery of physical access to spaces or services e.g. Providing a ramp for wheelchair access or giving children more time to complete a computer-based test, in schools for example. In the software example with kids, this basically amounts to offering more time to experience or work through stress, often caused by the lack of accessibility in the technology in the first place!
So, at Experience Dynamics, we believe taking an ‘Accomodations’ mentality to solving for accessibility is a cop-out. It does not position you as a strong designer or advocate of the group you are designing for. Nor does it embrace Universal Design principles, which strive for universal access as a default. Instead you need a new approach…
Note: These steps below are part of what we advocate at Experience Dynamics, and it’s taken us twenty years and much trial and error to refine them in our Accessibility work.
How to fix your broken Accessibility strategy
1. Broaden your definition of Accessibility Compliance. What is your goal?; What is driving it? Are solutions and goals only being defined from an Inside-Out perspective? Have you included any users viewpoints? Beyond compliance, what quality of experience are you striving for?
2. Define what your WCAG “AA” really means to your effort. Most organizations (including Apple- a big accessibility advocate), define compliance as meeting the W3 standard (WCAG 2.1) as “AA” compliant. But if everyone is AA, what is the point of AAA? Are you just covering your compliance backside, or are you trying to deliver a good user experience — for users with disabilities?
3. Avoid taking a pure automated, technology-driven solution to accessibility. Much of Digital Accessibility has grown up around “checker tools” (that is accessibility compliance checker tools). The idea is you run a checker, it gives you a report…you fix it and you’re done (maybe after re-checking, sure). But after 20 years of doing Web Accessibility optimizing, I can tell you — this is not enough. Checker tools are getting better, but you have to have users with disabilities test your work. Remember: User Experience always includes users. It’s no different with accessibility
Checker tools are great, but relying on them solely is dangerous and sloppy, so stop doing it. Everyone does and it’s creating a practice of “CYA (Cover your backside) accessibility”, that removes users from the process — a very foolish way to shoot yourself in the foot.
4. Get clear about what you mean by accessibility testing. Testing often gets used to mean internally performed code review or ‘checker tool’ (accessibility compliance checker tool) — aka internal review vs testing with actual users. Don’t say you are doing accessibility testing when you mean an internal or expert review, vs. testing with users of the representative disabilities. Both kinds of “testing” should be done.
5. Take a step back and validate what it is you are optimizing. Accessibility assumes the feature or software is the right thing, in the right format, presented in the right way. All these assumptions are dangerous according to UX Design best practices. Instead, take some time to profile user needs. Do field studies with your users with disabilities- find out how they are solving the problems you help them with, find out what tools, sites and apps they are using and that does not work/ does work for them…
In summary, if you start with accessibility as a “legal checkbox”, an ‘accomodation’ or a QA/optimization task, you are likely to miss the bigger picture of what accessibility efforts ought to deliver. Worse, you are likely to waste precious time and resources by delivering sub-optimal interfaces and experiences. Instead, take your good accessibility intentions (legal or otherwise) and follow good UX research and design practices:
- Define the problems you want to solve in accessibility from a user’s point of view.
- Include users with disabilities early on, let them influence goals and accessibility optimization efforts and have humans with disabilities test your software — not just automated compliance checker tools.
- Back-off compliance for a moment, and see if you are meeting the core user needs to begin with…define solutions from user observations and insights. Solve accessibility problems elegantly, while still meeting guideines--WCAG and Section 508 Refresh in the US; EU Web Accessibility Directive in Europe (or your country/region guidelines, which will likely point back to WCAG).
Best regards,
Frank Spillers
CXO @ Experience Dynamics