Skip to main content
Hey Domino’s, You’re Not Delivering
August 13, 2019 |

Domino’s Pizza has deliberately refused to fix their website for accessibility.

They’ve even gone as far as (costly) litigation by petitioning the US Supreme Court, alleging that the Americans with Disabilities Act (ADA) Title III Amendment does not apply to websites or mobile applications. This is a significant case, as it has the potential to set new precedence for website accessibility. Domino’s may think they are doing other businesses a favor by putting up this fight, but instead, they are doing a disservice to all businesses and those they serve (or could be serving). 

For nearly 30 years, the American Disabilities Act has benefited all Americans—not just those for whom the legislation was written.

In the physical space, are curb cuts not convenient for those of us rolling heavy luggage? 

Or how about the wheelchair door-opening button (as we have our hands full) when carrying items into a building? 

What about the text on subways or buses displaying the upcoming stop (because you used your headphones to tune out the noise while listening to your podcast)? 

These are all conveniences for our mainstream, national community, made possible by accessibility accommodations.  These benefits have a place on the web, too. They make our overall experience easier, logical, and stress-free—like those curb cuts, the automatic door openers, and the text prompts on Metrorail. They’re so ingrained in the experience, that we don’t necessarily stop to say, “Thank you ADA  for making this required.” Rather, we credit those who are the custodians of the experience e.g., “Thank you Metrorail for making sure I don’t miss my next stop!” or, “Thank Goodness JFK has curb cuts for my stroller carrying toddlers.”  Our satisfaction (and mood) increases because we’re not as prone to mistakes, accidents or missing out. In other words: accessibility is simply good design that benefits everyone.

Accessibility as a Revenue Opportunity

As a business whose sole purpose is to make and deliver pizza, the logical  priority for Domino’s is to get people to order a pizza in the first place. The way to do that is by creating experiences to make that possible. And guess what? It’s cheaper to implement the accessibility approach and process than litigation; cheaper to be a good custodian than a litigious proprietor.  What’s more, accessibility remediation isn’t necessarily about starting over to satisfy 20% of the users. It’s not about stripping away functionality or experiences to their bare parts. That might have been an (read: outdated) approach in the past, but design and development has advanced so much that accessibility has developed a new standard for all users, not just as  half-hearted nods to people with disabilities.In fact, it adds to the experience for all users.

Today, accessibility principles and user experiences are the ROI. 

Happy customers make repeat customers, right? But based on the case now in front of the Supreme Court, Domino’s seems adamant in wanting to not increase the number of happy customers. By petitioning the highest court in the land to be excused from website accessibility compliance due to “ambiguous requirements” and “burdensome” remediation, they are missing out on opportunities for:

  • Increased revenue
  • Improved conversion rate
  • Search engine optimization 
  • Lower bounce rates
  • Positive brand perception

Isn’t that just bad business?

And misleading other businesses into the belief that accessibility doesn’t help. By the way, website accessibility isn’t vague. Neither is it overly difficult. Or costly.

The Web Content Accessibility Guidelines (WCAG) not only clearly spells out the requirements but also provides a wealth of information on remediation approaches.

To prove it, we, at Phase2, audited a part of the Domino’s Delivery platform and here’s what we found...

Missed Revenue Opportunities

Quick side-bar: in a 2016 Microsoft & Forrester Study, “Assessing The Value Of Accessible Technologies For Organizations A Total Economic Impact™” estimated that for a middle-sized private company website that receives 1 million visitors per day, there is potential for for $2.5 million in additional revenue when accessibility is integrated into the experience. (It is estimated that 5% of people with disabilities abandoned site due to accessibility issues.) 



Caption: Table that multiplies 1,000,000 site visitors by 365 days a year, with a 2.5% average conversion rate, a $56 average basket size, and 5% of people with disabilities who abandon due to inability, totaling $2,550,000. 

Report, Page 19

Who’s Affected? Spoiler Alert: Everyone

Accessibility standards are only truly understood when experienced.. So in this post, I have a few YouTube clips of the keyboard and/or screen-reader experience, highlighting areas of friction in key UX milestones.. 

Who are users that might directly need accessibility standards in place? 

It could be a mom holding a newborn in her arms, trying to order her family pizza for dinner. This means she’s typing with one hand, or holding her mobile device with one hand, requiring quick navigation and ease of ordering a pizza. She may also be out in the park while her young kids play, under bright sunlight which reduces the overall screen contrast. She’s also gotta do it quickly—can’t let those kids out of sight!  With this in mind, I’m considering how much keyboard interaction is required, the color contrast, and ease of ordering.

It could also be someone who is illiterate and relies on a screen-reader to read aloud the contents of the screen. (A user of a screen-reader may also be someone who cannot see the screen due to blindness or vision loss.)  I go through the voice-over experience to ensure that the audible commands make sense, and there are predictable UX patterns to follow to help me along. To go the extra mile, developers, designers, and content creators should try the website or app blindfolded. It removes visual affordances and challenges us to really listen and make sense of the content that is being read aloud. [To learn more about this, visit: A Crash Course to Screen-Readers for Sighted Developers]

Getting Wider and Deeper: Examples of Failed Deliveries

A full evaluation Domino’s website would take more time, but for the purpose of this blog post, I’m covering a few key experiences and what we’d expect from an accessibility perspective. These are not necessarily the same ones that Guillermo Robles, a blind man who, over multiple instances, unsuccessfully ordered pizza due to incompatibility of his screen-recorder software with the website. (Mr. Robles filed the lawsuit against Domino’s in 2016.)

Inability to skip over long lists or sections of content

First, there was no quick way to “jump around” a page.  For users who cannot use a mouse, interaction and navigation is done through keystrokes. This can be accomplished by grouping elements or having appropriate use of landmarks. 

This is problematic because once the user made a selection of the pizza they would like to order, a pop-up dialog appeared. Another critical issue is that it did not receive immediate keyboard focus. (Keyboard Focus refers to the outline around interactive elements, and is the way to help users understand what is currently “selected.”) 




The lack of keyboard focus on the pop-up immediately after selection is problematic in a couple of ways:

  1. A user who cannot see the screen is unaware that there is a pop-up containing the very details required to build their pizza. So they are left wondering how and where to build the pizza. They may abandon the order out of frustration. That’s lost business. 

  2. A user, who can see but uses a keyboard for navigation, must navigate through the entire page in the background before it finally arrives on the modal, after it has gone through all the footer links. This is an incredibly frustrating experience. If they mess up on their order, they may abandon process so as to not go through the cumbersome process of tabbing through All The Links again.

The fix(es) are to ensure 

User is not alerted of changes in content

This issue comes up again, when the user selected a geographical location for coupons, the page refreshed but the user of a screen-reader is not made aware of an alert banner indicating that no coupons are available. Rather they continue through the panel, unaware that the options they select are inactive choices. To a sighted user, they recognize that it is an item unavailable to the coupon. But this information is not passed to the user who cannot see the screen. 

Interestingly, they could still make the selection, unaware that they are ordering a pizza without a valid coupon.  They are being misled here. They may cancel the order because they could not use the coupon. 



The fix to this is to ensure that the user of a screen-reader is taken to the alert modal once the page loads that notifies them of the lack of results, as well as providing appropriate messaging of inactive options.

Tables on the Check-Out Page 

On the check-out page, each item was “contained within a table” yet it lacked headers. So when I heard “$12.99” I wasn’t clear on exactly what that covered. Is it $12.99 as the total? The coupon amount? The cost of one pizza? Lots of improvements can be made on this page. The user may abandon the cart out of confusion or fear of making a mistake.




Color Contrast

There are multiple issues with the color combinations on the Domino’s website. This is problematic for people who have low vision or are viewing on a mobile device under bright sunlight (like the any-given-mom I mentioned before). Notably, the red text over white fails contrast requirements, as does the disclaimer text at the bottom which is dark grey over grey. The red text is an important text-aspect of the site, for it’s the confirmation of the order, like in the screenshot, ‘Large 2 Topping Pizza.” Did I also mention that 8% of men have red-green color blindness? \



These examples are actually quite common on many websites, but with advance planning, baseline accessibility knowledge, and UX considerations, these are fixable issues. In fact, this is one of the areas that automated checkers do a good job of catching for issues. Considering the color contrast in the beginning of the process is a more efficient approach. But now time must be spent to analyze and design a new color scheme that meets compliance. Designers may use tools like to help them find the next closest color that would meet requisite contrast minimums. In the example below, I am choosing from a palette of compliant reds that will be at least 4.5 ratio. 




Website Accessibility as a Process

With basic planning, prioritization, and simple remediation strategies, these issues can be fixed over time. Website accessibility is not a one-and-done job; it’s a work in progress that requires collaboration among all teams from user experience to development, content and quality assurance. Over time, within an organization, accessibility becomes more ingrained and ‘cheaper’ because best practices are baked into the process and there’s less need to retrofit or redo code to become compliant. 

Accessibility Fixes Aren’t Ambiguous, Expensive or Impossible

The Domino’s petition and message perpetuates the myth that accessibility compliance is a distraction and unnecessary expense. This is wrong. And there’s 30 years of evidence to prove it. And by the way, we shouldn’t need (or wait for) a Supreme Court ruling to do what’s right. It’s evident that accessibility benefits everyone and at Phase2, we’re committed to advancing the digital experiences for anyone. 

So Domino’s, whether SCOTUS gives credence to your case or not, we’re here to help you deliver to more people—when you’re ready to deliver on your promise.




Catharine bridges the accessibility gap by strategically working to create an equal web for all users, regardless of their ability. With an eye towards efficiency, scalability, and empathy, Catharine's expertise guides solutions for creating truly inclusive digital experiences. Her process-driven and consultative approach ensures accessibility is addressed in the beginning and not as an after-thought. 

Jump back to top