The Domino's Pizza case is one that is interesting to me for a few reasons. First, this case initially broke when I was just getting into web accessibility. I had just started at Voya Financial, in one of my first weeks. I was tasked with performing accessibility audits on a few of our sites, and some for our clients as well. The problem was I had never even HEARD of web accessibility before this. So over the next few weeks, I consumed myself with learning as much as I could: I went through every accessibility tutorial I could find, read every blog post on the subject I could find, read the standard on what a website must do to be accessible, and even watched as many videos as I could showcasing how users with disabilities navigate the web and the tools they use to assist them.

The second reason this case stuck out to me is that it's also relatable. Most of us have used the Domino's app, refreshing the Pizza Tracker, anxiously following along with every step of the pizza lifecycle. The pizza is okay - not great, not terrible - but the app is convenient and for me, it works pretty well so it keeps me coming back.

After diving deep into the technical aspect, I couldn't help but wonder about the legal aspect of it as well. I typed "web accessibility lawsuits" into Google and there it was - one of the very first results - Man sues Domino's over inaccessible website.

But it's also not just Domino's that have had their day in court. Burger King, Netflix and Nike are just a few of many more that have been sued over web accessibility. And the number of accessiblity lawsuits are still growing year over year. Clearly, this is a problem - so let's take a deeper look so we can understand how to solve it.

What is web accessibility?

Before we examine the Domino's case, we first have to understand web accessibility at an introductory level. The World Wide Web Consortium defined web accessibility to mean "that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the Web" as well as "contribute to the web".

Basically, we can think of it simply as eliminating any barriers that would prevent someone from being able to use your site. Picture this scenario: you're reading a news article or blog post on your phone, and as you scroll through a modal with an ad pops up. Just wanting to get back to the article, you attempt to tap X out of the modal but it's not responsive - or even worse, it registers as a click on the ad and now you're looking at dog food or whatever else pops up. It's frustrating, and an example almost all of us can relate to, regardless of disability status, of a website being inaccessible because it leaves the user unable to navigate.

What happened with Domino's?

On July 18, 2015, a man named Guillermo Robles attempts to order a pizza using his laptop. Guillermo is blind and relies on screen reading software. Operating Systems can include screen reading software - such as VoiceOver for iOS/Mac devices and TalkBalk for Android devices. In this case, Guillermo was using JAWS, a popular screen reader for PC. Vision impaired users rely heavily on screen readers to announce the elements on a webpage and help them navigate. According to court documents, Guillermo was unable to complete his order due to issues with portions of the Domino's website not being visible to the screen reader due to coding errors. Guillermo further states he attempts to order Domino's in the following years and was still unable to.

Meaning, for years, these accessibility issues sat there. Domino's of course was aware of the lawsuit, and instead of just fixing the issues (which would have been cheaper), Domino's made the genius marketing decision to actually fight the lawsuit and the disabled community. I've been seeing this case play out for over the years since I first saw it wondering "What the hell are they thinking?". Others in the development community at the time shared in my head-scratching.

Like, is it really cheaper to litigate than to just hire some a11y experts for your web team??

— Dave 'PfizerBoosted' Swersky 💉💉💉🎉 (@dswersky) October 7, 2019

The Result

After a number of appeals, on June 23, 2021, a federal judge ruled that Domino's had violated Title III of the Americans with Disabilities Act (ADA) with their inaccessible website. Domino's was ordered to fix not just the issues that prevented users like Robles from placing an order, but any and all accessibility issues on their site. For his troubles and 5+ year battle with Domino's, Robles was awarded a grand total of ... *checks notes* ... $4,000. So after all that: a marketing disaster, ridiculous attorney fees, and a small settlement award later - Domino's STILL has to update their website for accessibility.

How can we fix it?

I believe the key here is empathy - the ability to understand and share the feelings of another. Earlier in the blog, I referenced that the Domino's app was convenient and "for me" it works pretty well. The problem with that is it's easy to test a website and have the attitude that "it works well for me". But web accessibility is about your app or website working well not just for you, but for everyone.

The precedent has already been set: businesses are losing their fight against web accessibility. And with that loss usually comes the same court ruling: Your website must be updated to meet WCAG guidelines. WCAG (Web Content Accessibility Guidelines) are a set of web accessibility guidelines that websites must follow to be considered fully accessible. Courts have been referencing WCAG (latest version 2.1) in their verdicts.

Yeah but, how do we technically fix it?

The easiest solution is to develop any new applications with accessibility in mind WHILE building them. When hiring, look for developers that have an understanding of web accessibility. Or if you are a developer, make sure you know what it means to make a website accessible (Udacity has a great free course that serves as a good intro to accessibility). Don't wait until your product is launched and in the wild to mediate any accessibility issues.

But let's pretend you didn't take that advice and have an existing site. I've completed many accessibility audits and remediation and this is my exact process:

Step 1: Get a baseline

First, you have to know where you stand accessibility-wise so you will need a tool that will help you automatically scan your webpage. It's important to remember that only approximately half of all accessibility errors can be caught with automated tools. The other half of errors fall into 'manual testing' that I will describe further below.

For the automated half of the audit, my choice is the axe DevTools extension for Chrome. axe-core is the engine that powers the Chrome extension, and axe-core is also what Google itself includes inside Chrome when it runs Lighthouse audits. I've built tools that will help you scan any number of pages programatically and automatically generate reports suitable for larger sites, but for this case we're just going to be testing one URL at a time using the browser extension.

For this example, Colorado State University hosts an intentionally inaccessible website. Hopefully this is just a nightmare scenario, and when you audit your own sites you have less errors pop up. But we'll examine it for demoing purposes.

After you audit a URL using axe, you will be presented with a list of issues. The thing I really liked about axe was with each issue it gave you a tab for more info which would show you exactly where in WCAG the issue is referenced, as well as an explanation of WHY it is an accessibility issue. Record the results and test a few additional pages on your website.

Manual testing

Tools like axe provide a great starting point. But as mentioned earlier, you'll also need manual testing. I'll seperate these into sections as follows:

Keyboard testing - Test your website without a mouse. Tab through the links, make sure you can open and close any modals with the keyboard.

Screenreader testing - Download a screen reader like JAWS or use TalkBalk on Android or VoiceOver on iOS. Navigate through the site. Do things make sense? Is anything not getting announced that should be? Or is anything poorly labeled to the screenreader?

Step 2: Fix it

I won't go too in depth here to keep it short (this is an introduction after-all). But you should review the data you collected in step 1. It's highly possible you start noticing patterns of issues - every page missing a language attribute, the same color contrast violations, etc. This is my starting point, just trying to knock out the most commonly repeated issues first.

Accessibility isn't this scary expensive monster that some people in the business world seem to think it is. For example we once audited a site that had roughly 100 violations per page according to our automated accessibility checker. But looking further, roughly half of them were color contrast issues in the header and footer. We could fix these quickly by just tweaking the font text and background text colors a few shades lighter or darker. Then suddenly 50 violations per page sounds a lot less scary than 100 violations per page, and you can just keep working them down from there.

Cya ✌️

Thanks for reading! If you're looking for accessibility help with your website keep us in mind!