Domino’s Pizza: The Accessibility Lawsuit That Reached the U.S. Supreme Court

Few digital accessibility cases are cited as often as Robles v. Domino’s Pizza. The dispute—about a pizza chain’s website and mobile app—didn’t result in a Supreme Court opinion, but it did reach the Court and sent a clear signal to businesses: ADA risk is real when people can’t access online goods and services.

This article breaks down what happened, why it mattered, and what organizations should do now to align with WCAG, reduce legal exposure, and—most importantly—serve customers with disabilities.

What the Domino’s accessibility lawsuit was about

The case began when a blind customer, Guillermo Robles, alleged he couldn’t order a customized pizza using Domino’s website and mobile app with his screen reader. The core claim: the digital barriers blocked access to goods and services offered by a place of public accommodation, violating Title III of the Americans with Disabilities Act (ADA).

In other words, the lawsuit wasn’t “about the internet” in the abstract. It was about the practical reality that the website and app functioned like a front door to ordering—especially for deals, customization, and delivery workflows that are difficult or impossible by phone.

The accessibility issues at the heart of the claim

While the case filings discuss barriers in broad terms, the kinds of issues that commonly block screen reader users in ordering flows include:

• Unlabeled buttons or icons (e.g., “Add to cart” icons without accessible names)
• Poor keyboard navigation (focus trapped in modals, or focus order that doesn’t match the visual layout)
• Inaccessible customizers (topping selectors built as non-semantic widgets without ARIA patterns)
• Error handling that isn’t announced (validation errors not associated with fields or not communicated to assistive tech)
• Dynamic updates (prices, totals, or cart changes that don’t notify screen readers)

These barriers map directly to familiar WCAG requirements, such as non-text content, name/role/value, focus order, error identification, and status messages.

How the case reached the U.S. Supreme Court (and why that mattered)

The legal path is part of why the Domino’s case became so influential:

• A federal district court initially dismissed the case, reasoning (in part) that the U.S. Department of Justice hadn’t issued specific website accessibility regulations, raising “due process” concerns.
• The Ninth Circuit Court of Appeals reversed that dismissal, holding that the ADA could apply to Domino’s website and app because they connected customers to the goods and services of physical restaurants.
• Domino’s asked the U.S. Supreme Court to review (via a petition for writ of certiorari).
• In 2019, the Supreme Court declined to hear the case, leaving the Ninth Circuit’s decision in place.

Even though there was no Supreme Court ruling on the merits, the denial effectively reinforced a trend: businesses shouldn’t assume they can wait for perfect regulatory clarity before making their digital experiences accessible.

What “cert denied” means for businesses

When the Supreme Court declines a case, it doesn’t create a nationwide precedent by itself. But the practical impact is still significant: lower-court interpretations continue to shape expectations, and plaintiffs can point to decisions like Domino’s as evidence that ADA claims tied to digital access are viable—especially when online systems are integral to accessing in-store goods and services.

The bigger takeaway: WCAG is the benchmark, even when laws don’t name it

A key tension in U.S. accessibility compliance is that the ADA is broad, while WCAG is specific. Courts and settlements often use WCAG (commonly WCAG 2.1 AA) as a measurable standard for what “accessible” should mean online.

If you operate across jurisdictions, it helps to understand how WCAG connects to other frameworks, too. For example, the EU’s technical requirements often reference WCAG through standards like EN 301 549. For a deeper explanation of how these standards interrelate, see EN 301 549 and WCAG explained for digital accessibility compliance.

What companies should do now: practical WCAG steps that prevent “Domino’s-style” risk

The Domino’s case is a reminder that accessibility isn’t a one-time project. Ordering flows change, design systems evolve, and new promotions ship weekly. A durable approach combines governance, testing, and ongoing monitoring.

1) Audit the customer journey end-to-end

Don’t audit only the homepage. For commerce and service sites, focus on the workflows that create value:

• Account creation and sign-in
• Search, filtering, and product configuration
• Cart updates, coupons, and promotions
• Checkout forms, payment steps, and confirmation
• Order tracking and customer support

Automated scanning can catch common failures (missing labels, color contrast, invalid ARIA), but you also need manual checks for keyboard usability, screen reader output, and dynamic content behavior. Platforms like Corpowid (corpowid.ai) can help teams run automated accessibility audits and continuous monitoring so regressions are detected early—before they become customer complaints or legal headaches.

2) Fix the fundamentals: semantics, keyboard, focus, and errors

If you need to prioritize, start with issues that most often break ordering experiences:

• Use semantic HTML (buttons as <button>, headings in order, form fields with <label>).
• Ensure complete keyboard access to menus, customizers, and dialogs; don’t rely on hover-only interactions.
• Manage focus when modals open/close; keep focus visible and predictable.
• Make errors understandable: identify errors, describe how to fix them, and associate messages with fields.

3) Don’t use an overlay as a substitute for accessible code

Overlays/widgets can help with certain user preferences (like text spacing controls) and can be part of an accessibility program, but they shouldn’t be treated as a replacement for underlying WCAG fixes. If core components are inaccessible—like a topping selector or payment form—an overlay cannot reliably “patch” the experience for assistive technology users.

A stronger strategy is “build accessible by default,” then use tools to support maintenance. For example, Corpowid can support accessibility operations with monitoring and accessibility statement tooling, while teams remediate root issues in the design system and front-end components.

4) Publish an accessibility statement and operationalize feedback

An accessibility statement sets expectations, provides contact channels, and demonstrates good-faith effort. More importantly, it creates a feedback loop: when real users report barriers, you can triage, fix, and prevent recurrence.

Accessibility is also increasingly tied to privacy and consent tooling (cookie banners, preference centers, authentication). If your compliance stack is fragmented, you may unintentionally introduce barriers. This is one reason many organizations are aligning these efforts; see why accessibility and privacy are converging and how that affects implementation choices.

Inclusive design lessons from Domino’s: accessibility is customer experience

The most enduring lesson from the Domino’s lawsuit is not just legal—it’s operational. If customers can’t complete key tasks independently, they’re effectively excluded. Inclusive design reframes accessibility as a quality metric:

• Design systems should ship accessible components so teams don’t reinvent patterns.
• Product managers should define “done” to include accessibility acceptance criteria.
• QA should test keyboard and screen reader basics on every release impacting critical journeys.
• Content teams should ensure clear labels, helpful error text, and meaningful alt text.

These practices matter across industries—from food ordering to education portals and beyond. If you’re building for students, faculty, and the public, accessibility stakes are just as high; this guide on digital accessibility for universities and educational institutions offers a practical WCAG-oriented perspective.

Why the Domino’s case still matters in 2026

Years after the Supreme Court declined review, Domino’s remains a shorthand for a simple principle: if your website or app is a gateway to your business, it needs to work for people with disabilities. Regulatory details may evolve, but user needs are consistent—and WCAG remains the most widely accepted yardstick for meeting them.

Teams that treat accessibility as continuous improvement—auditing critical flows, monitoring changes, fixing root code issues, and maintaining clear documentation—are best positioned to reduce legal risk and deliver better experiences for everyone.

And if you’re also navigating complex compliance requirements like cookie consent across regions, it’s worth ensuring those solutions don’t introduce new barriers; this practical resource on multi-region cookie compliance without breaking accessibility can help connect the dots.