Digital Accessibility: An a11y in lawsuit avoidance
Disclaimer – I am not a licensed attorney and Prolific Interactive is not a law firm. Please contact your legal counsel for details and questions about your unique accessibility situation.
Many companies struggle with the financial feasibility of making their digital product ADA compliant. They usually start with good intentions of helping differently-abled people, but plans get derailed when they realize all that compliance can require. There’s no easy checklist to follow to avoid a lawsuit, but developing user empathy will get you pretty far. It’s all about being an a11y.
- Shorthand for being an accessibility advocate
- Origin: breaking down the word “accessibility” with only the first and last letters, plus the 11 letters in between (a11y).
- “Being an a11y will help your company avoid getting slapped with a lawsuit, and make your product available to a growing population who want to buy your products and services.”
What’s the big deal?
Even if you start with what Apple or Android gives you out of the box, it’s not necessarily preventing you from getting sued– and doesn’t automatically extend your services to users with differing abilities. Here are the four things to get you started on the path to being not only compliant but inclusive.
Who are we talking about?
First, “disabled” means more than wheelchairs. Legally, the landscape of people who meet the “disabled” criteria is vast and complex. To embrace the full scope of users, we need to think of people who aren’t considered traditionally “disabled.” Consider the stubborn guy who insists he doesn’t need a hearing aid but probably needs one; think about the woman who is operating with a limited budget from her disability allowance and can’t afford any assistive devices. What about someone who uses a pointing device to navigate both their tablet and the rest of their life?
When you think about how mobile devices fit into these people’s lives, the focus narrows. Your app or mobile site can realistically and significantly lessen the burden of their day, and when you neglect their needs you’re missing both a market opportunity and a chance to help.
Compliance isn’t optional
The Americans with Disabilities Act (ADA) of 1990 prohibits discrimination against people with disabilities in relation to the obvious physical spaces as well as “public accommodations” and “communications.” It applies to public and private entities and the DOJ has yet to determine its own specific regulations. The Amendment to the Rehabilitation Act of 1973 (specifically Section 508) requires federal agencies to make their electronic and information technology accessible to people with disabilities.
Basically, the law says that the internet and your apps have been deemed public spaces and must be made accessible to people with different levels of abilities.
How do we do it?
The World Wide Consortium team and the Web Accessibility Initiative (WAI) put together the Web Content Accessibility Guidelines (WCAG), which the closest we have to any real, official, “Do this and you probably won’t get sued” guidelines. These standards are organized under four basic principles of design, and in order to be considered accessible, your digital offering must be:
- Perceivable – The information presented can’t be invisible to all of their senses.
- Operable – The interface cannot require interaction that a user cannot perform.
- Understandable – The content or operation cannot be beyond the users’ understanding.
- Robust – Users must be able to access the content via the wide variety of user agents, including assistive technologies.
That doesn’t look like a checklist
Fuzzy is a kind way to put it. WCAG outlines the specifics of designing and developing your product to support these principals, but it’s far from exhaustive. They are purposefully vague to cover a range of accessibility issues, but designed to be targeted enough to tell if you are upholding the spirit of the principle or not.
Another thing about these guidelines is that up until now we’ve had version 2.0 which is mostly web (desktop) centric, with little guidance about apps or mobile web. A more mobile-focused version of WCAG 2.1 is currently in review. But meeting the WCAG web standards isn’t going to safeguard you from a lawsuit, and is only a small step toward meeting the needs of your growing customer base with accessibility needs.
What to do in the meantime
- Start with the biggest key user flows.
Are you a retailer selling clothing? Make it possible for your user to browse products, add them to the cart, and check out. Then think about the next user flow. Concentrating on the full end-to-end task instead of checkboxes ensures that at least a few tasks can be executed in their entirety. And it’s a lot less overwhelming. If you focus on technical requirements, you might miss that one part of the flow that breaks the whole experience – that’s where you have a compliance issue.
- Formulate your compliance statement
You will never be able to plan for every type of usability issue. Include a statement that outlines what you’ve done, what key flows you’ve prioritized, how you prioritized them, and what’s next on your roadmap. Being open and transparent about your usability roadmap is key to showing the good faith effort you’ve made already. And make it easy to find!
- Welcome feedback
Offer an easy way for users to contact you about your efforts to address their needs and suggest improvements. Opening a dialogue with users is the best way to make sure you are part of the conversation and gives you an opportunity to plan for the user flows that matter most to your customers.
- Roadmap Accessibility Testing
Build accessibility testing into all phases of your product lifecycle. It’s easier to plan to build accessible wheelchair ramps into your building plan than to try and retrofit entries after the fact.Plan your testing cycles to include participants with accessibility issues. Local organizations are usually more than willing to connect you with people who are excited to test your products. Another great next step is to get your team to keep accessibility at the top of mind throughout the product life cycle. Spend 15 minutes trying to shop on your site with a screen reader. Try navigating your website with only a keyboard. You’ll be shocked at how hard it is.
Listening to actual users and taking action based on their feedback is the only way to practically increase accessibility. It can’t just be about following a list and checking off boxes. To avoid nasty lawsuits you actually need to be a real a11y and not phone it in. Keep users of all abilities at the top of your mind. Making your offering accessible is good for your company and good for everyone.
Here’s more information about how to think like an a11y:
Vox Product Accessibility Guidelines
If you’re still craving a checklist, here you go. Remember, it’s only a starting point– people aren’t checkboxes– but this could help you get going.
A great collection of accessible design patterns from a community of designers and developers who are constantly iterating and making them more robust.
Web Accessibility Evaluation Tools List
A repository of tools from WCAG that can help give you a framework for testing. Note that it is specifically focused on web. Native application design and development will need extra care and feeding to be considered compliant.
Designing for Accessibility is Not That Hard
A well-written, easy-to-digest article by Pablo Stanley with starting points to thinking like an a11y. It’s a great, useful read.
This non-profit makes it their “mission to empower organizations to make their web content accessible to people with disabilities.” Again, not native-focused. This is a helpful resource to find consultants and communities to join a dialogue about bringing accessibility to your offering.
A11y Weekly Newsletter
The best way to keep yourself informed on the changing landscape is to listen to the community and participate in the conversation. This weekly wrap-up is a great resource to keep accessibility on your mind.