On January 15th, the 9th District Court ruled against Domino’s Pizza in a case that, if you are paying attention, telegraphs a topic that should be on every website, web application and mobile application developer’s mind.
The court found that websites, web applications, and mobile applications were, indeed, mediums covered under the ADA, which ensures that people with disabilities enjoy parity of access with able-bodied individuals.
“The panel reversed the district court’s dismissal of an action under Title III of the Americans with Disabilities Act and California’s Unruh Civil Rights Act, alleging that Domino’s Pizza’s website and mobile application were not fully accessible to a blind or visually impaired person.
The panel held that the ADA applied to Domino’s website and app because the Act mandates that places of public accommodation, like Domino’s, provide auxiliary aids and services to make visual materials available to individuals who are blind. Even though customers primarily accessed the website and app away from Domino’s physical restaurants, the panel stated that the ADA applies to the services of a public accommodation, not services in a place of public accommodation. The panel stated that the website and app connected customers to the goods and services of Domino’s physical restaurants.” (Robles v. Domino’s Pizza)
There are guidelines out there for developing ADA accessible software solutions. Art+Logic recently worked on two such endeavors and leaned heavily on the WCAG 2.0 (Web Content Accessibility Guidelines) documentation for these efforts. Both clients undertook this solution for their projects because they felt that not being ADA compliant left them open to lawsuits. Serving differently-abled communities was central to the mission statement and culture of each client as well.
These efforts weren’t trivial. The WCAG are fairly new and fluid. Our earliest project certainly wrestled with the guideline’s ambiguity. In some instances, the client, when faced with the absence of a specific guideline, concluded that they had made a good-faith effort to meet the needs of those differently-abled populations and that would have to be enough.
On our more recent project, development was more sure-footed, as we were now using the 2.0 documentation. Additionally, the client brought in a panel of target users to test the site as we developed it. These users provided critical feedback, as a sighted person has a really hard time testing as a visually impaired person. I even would suggest that they can’t.
Combining these two methods of arriving at an ADA-compliant website that met both the letter of the WCAG 2.0 documentation and actual users’ needs, ensured that, even if an accessibility lapse was exposed, or later documentation addressed a need differently, the client and Art+Logic could prove a good-faith effort was made. More importantly, those actual users confirmed that, regardless of documentation compliance, the site met their expectations.
Eventually, we suspect that the tools and technologies of software development themselves will “bake in” ADA compliance – but we are a ways off from that.
Until then, we encourage software owners to consider an effort to update the front-end of their applications to be WCAG 2.0 compliant. It’s far more cost-effective to undertake an update then to pay lawyers to defend you in court.
