The fight started over a pizza. Except this wasn’t a barroom brawl. It was a question of whether a vision impaired internet user should be able to order a slice of their favorite pie from the Domino’s website using a screen reader. It became such a big conflict about web accessibility that it went all the way to the Supreme Court. It was a real-life David vs. Goliath battle.
The outcome? Chalk up a win for the little guy, and a big win for everyone who relies on assistive technologies to use the internet in a way most people take for granted.
The consequences of the Supreme Court’s decision will be far-reaching.
The impact will range from minor inconveniences, fixed with simple workflow improvements, to major investments by enterprises as they update complex software platforms, write process addendums, hire developers with accessibility experience, and train their staff.
Anyone employing “non-technical” staff to create public facing content should take the Court’s decision very seriously.
Specifically (in the context of the Court’s determination on the Domino’s case), the retail industry will be impacted significantly. The Los Angeles Times writes:
In a potentially far-reaching move, the justices turned down an appeal from Domino’s and let stand a U.S. 9th Circuit Court of Appeals ruling holding that the Americans With Disabilities Act protects access not just to restaurants and stores but also to the websites and apps of those businesses.
The start of a pie fight
The case against Domino’s was brought by Guillermo Robles (who is blind) after he was unable to order pizza using the Domino’s website and app. See the case summary for specifics, but the key takeaway is that the Americans With Disabilities Act applies to retailer websites.
In response to the Supreme Court’s decision, Stephanie Martz from the U.S. National Retail Federation said in a statement:
With a growing number of website accessibility cases being filed and conflicting rulings from circuit courts across the country, this is an issue that needs the clarity of a Supreme Court ruling. Without guidance on what rules should apply, litigation will continue to divert resources from actually making websites accessible.
Let’s repeat that for effect, the NRF says a growing number of website accessibility cases are being filed. Momentum is building and it’s time to act.
If any of this resonates for you, because you create content, you’re the CTO or CIO of a public company, or simply because you care about everyone having the same access to information and services most of us take for granted, what can you do to avoid a legal fight over your equivalent of pizza?
1. Train all staff who create content to understand basic computer programming
There are more than a dozen potential accessibility (“a11y”) issues that can exist in content (see the next point). These are mostly found in HTML, with some in CSS. Your team will need to ensure their content meets the a11y guidelines. This can be a time-consuming task and a distraction from your core purpose, more than it is difficult. Fixing errors is another matter.
Most content management systems provide a manual way to add some a11y requirements, such as image descriptions, and where they don’t, there’s often an HTML source code view available to the user.
If the issue is more complex, like fixing color contrast ratios, for example, you’ll start to run up against some blockers. Inlining styles requires knowledge of both HTML and CSS, and is not good practice for a whole number of reasons. Plus, your web and marketing teams will go bananas when site styling starts to break.
2. Train your staff to understand the WCAG and 508 rules and requirements
Before your team can implement the suggestions above, you’ll need to train them on basic a11y compliance. There are about a dozen major a11y requirements they need to understand.
For example, tables should have a header row, and text to background color contrast ratios should be at least 4.5:1. To make this more complex, color ratios may vary depending on color.
Again, this is the kind of thing that’s probably not one of your employee core competencies (let alone in their job description).
3. Implement workflows to pass content through a11y review
We’re starting to get a little more practical now. Most authors simply want to write their blog posts, input patient notes, update files, or add the new seasonal pizza offering to the website. They don’t want to understand Web Content Accessibility Guidelines (WCAG) specifications, or learn how to write HTML.
But there are probably some people on your team who already do this. If you have a web development team, or employ editors with developer skills, an option is to inject them into the content pre-publishing process.
Provide an error checklist, and before anything hits a public facing web page, have the content reviewed. It’s likely to be time-consuming and slow down content production, but it’s better than getting sued.
4. Buy accessibility compliant platforms and solutions and speak with existing vendors
As mentioned, a lot of content platforms already make it relatively easy for authors to add descriptions to images, and the like. Speak with your vendors about their a11y support. Ask them if they provide a11y error checking.
Ask if they have ways to make it easy for authors to comply with the Americans with Disabilities Act.
If your technology vendors cannot deliver this for you (and remember, there’s a good chance any company in the Fortune 5000 is now a legal target), get them to speak with our team. We can likely provide guidance or recommend ways to deliver the kind of solution you need.
5. Automate accessibility checking for content creators
Your authors typically won’t have HTML experience, nor WCAG or Section 508 knowledge, and aren’t likely to be happy about the introduction of pre-publishing technical reviews.
You should automate checking where you can. Make it easy for authors to add descriptions to their images, header rows to tables, and ensure that HTML headings are applied in sequential order.
6. Design and build applications with accessibility in mind
The Domino’s case was brought by a blind man who couldn’t order a pizza because the website didn’t work with his screen reader. Although the first 5 points focus on the content creation experience*, you still need to build compliant websites and apps.
This does mean someone on your product, design, or engineering teams should understand the relevant aspects of the ADA. It means you will need to build a11y compliant sites and apps. You’ll need testing frameworks in place, and a11y validation tools. If your web properties are at the enterprise scale, you might even consider hiring a11y consultants.
* Tiny can help specifically with accessibility for content authors.
An a11y checklist
Even if you have all of this locked down, we recommend automating some aspects of the a11y process, from content creation through to site tests. Below you’ll find some resources that can help you on your way, including a fantastic a11y checklist available from The A11Y Project. You’ll also find lots of info on our blog, including 12 tips to make your website accessible, and accessibility best practices for learning management systems.
Web and app accessibility matters, and with recent legal challenges around accessibility, it is becoming a fundamental part of doing business.
So let’s make sure accessibility stays on the menu.
