Summary: Doing Digital Accessibility, including Web and Mobile, requires that you take a proactive approach, using good UX research and design methods. Anything short of that will undermine 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, a blind man sued Domino’s pizza because he was not able to access the company’s website. The blind man won, and Domino’s appealed. The logic of Domino’s appeal reveals a lot about why Web Accessibility is not done, or is done poorly. 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)
The US Supreme Court ruled against Domino’s appeal. This ruling provides not only a wake-up call, but also an opportunity to reset such long-held attitudes that won’t be defendable in court moving forward.
It’s time to ditch the ‘Accomodations’ Mentality
Many organizations are in a similar place as Domino’s in regard to Accessibility. The assumption is that by taking a reactive and “minimal interpretation” of access, companies can help meet the requirements dictated by laws, guidelines, and standards. This view is part of the ‘accommodations’ 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 then see accomodations as only a legal obligation. In many cases the ‘Accomodation’ doesn’t help or improve the access experience. It simply provides a legal check box.
The ‘Accomodations’ mentality developed out of the delivery of physical access to spaces or services Providing a ramp for wheelchair access or giving students more time to complete a computer-based test in schools are two examples of ‘accomodations’. In the software example with students, this basically amounts to offering more time to experience or work through stress. The irony is that this is often caused by the lack of accessibility in the technology in the first place!
Therefore, 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 for whom you are designing. Nor does it embrace Universal Design principles, which strives 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 20 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 purely 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 that first you run a checker. Then, it gives you a report, and you fix the issues reported, maybe after re-checking. You have met your Users’ accommodations needs, right? 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 is 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’ (digital 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. You should conduct Both kinds of “testing”.
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. You should 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.
Truly listen to the user
In summary, if you start with accessibility as a “legal checkbox”, an ‘accommodation’ or a QA/optimization task, you are likely to miss the bigger picture of what digital 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
