Web accessibility has been buzzed about for years, but many companies have yet to fall in line. However, because of a recent lawsuit, that all needs to change going forward. We'll examine why web accessibility is a must, as well as 35 things you can do today to make your websites and apps accessible for all users.
Accommodations are made for those with impairments all around us in the physical world. Ramps help those who are physically impaired walk into stores. Closed captioning is available to hearing impaired movie-goers. Braille menus enable visually impaired diners to order from menus on their own.
So, why is it that the Internet is so far behind?
Is it really that expensive and time-consuming to create websites and mobile apps that are fully accessible? Or is it that there aren’t enough impaired consumers screaming loudly about inaccessibility where the issue has yet to be taken seriously?
Whatever the reason has been until now, that’s all about to change, thanks to the Supreme Court’s smackdown of Domino’s.
Today, I’m going to recap what happened with Domino’s, explain how this affects you as a web developer or designer, and suggest what you can do moving forward to create a more accessible web.
Back in 2016, a visually impaired man named Guillermo Robles filed a lawsuit against Domino’s. In it, Robles asserted that his screen reader was unable to access the Domino’s website and mobile app in full. Domino’s was ordered to bring its digital properties into compliance.
Domino’s, however, has been putting up a fight for years, arguing that websites and mobile apps are not required to be accessible under the ADA.
In its lengthy request for appeal, Domino’s argues that Title III of the ADA was written before the web (which is true). And because the Supreme Court has failed to clarify whether or not the law applies to web properties as it does brick-and-mortars, Domino’s argued it should not be held accountable for making these changes (which is not really true).
The United States Court of Appeals for the Ninth Circuit responded with the following:
“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.”
Even if the ADA has yet to be officially updated, the Supreme Court’s ruling against Domino’s has set a pretty clear precedent for the future of the web:
If your websites or mobile apps connect users to the products or services provided, they need to be accessible.
Beyond the Supreme Court’s ruling and what it dictates, let’s think about this from your clients’ and users’ points of view.
According to the Web Accessibility Initiative (WAI):
“When websites and web tools are properly designed and coded, people with disabilities can use them.”
So, accessibility removes barriers to entry. That’s what you’re aiming for when you design any website or app anyway, right? You want to remove all friction so that as many users as possible will convert. Why shouldn’t accessibility standards be included in that then?
The WAI also suggests that:
“Making the web accessible benefits individuals, businesses, and society.”
If you’re still struggling to see how spending the time to make a site or app accessible is worthwhile, think about it like this:
Inaccessibility affects disabilities of all kinds:
But that’s not all. Accessibility helps close the gaps people may have in their experiences due to:
In other words, it’s not just a tiny segment of the population that’s affected by inaccessible digital properties.
Whether you’re building a website or app from scratch, or you need to revisit an existing one, the list of accessibility standards is pretty clear. You can refer to the WCAG 2.x guidelines here, or you can use the following checklist to make sure you’ve checked off all the major boxes:
☐ Mouse or scrolling functionality is available by keyboard.
☐ All components of a website or app are tabbable.
☐ Keyboard focus always remains in view so the visitor knows exactly what they’re interacting with.
☐ Navigation is easy to locate and predictably placed from page to page.
☐ Navigation buttons are clearly labeled.
☐ Navigation buttons are large enough to click without error.
☐ Breadcrumbs are provided for pages deeper than the top level.
☐ Pages are uniquely labeled at the top.
☐ Color palettes and pairings won’t prevent color blind users from being able to discern the content.
☐ Color isn’t used as the sole way to convey information (like a form error).
☐ Significant color contrast is provided between foreground and background.
☐ There’s significant color contrast between text and the background.
☐ Text resizing and spacing tools are available.
☐ Viewports are configured to properly reflow in text after it’s been resized.
☐ If text is placed images, the text should be independent of the content of an image.
☐ Alt tags are provided for all non-text content.
☐ Each alt tag is descriptive of what people can see in the content. This includes any text or numbers in the graphic.
☐ If attached to a video or audio clip, a brief summary is all that’s needed.
☐ Auto-play audio can be paused, stopped, or the volume adjusted.
☐ Other audio and video must actively be engaged to play and should begin at a low or no volume.
☐ Captions are provided for videos.
☐ Transcripts are provided for videos or audio clips.
☐ If important visual or aural details are present in video or audio (like a graph displayed on screen or music playing in the background), additional transcripts are provided.
☐ If the site contains potentially seizure-inducing animations or graphics, users can turn them off or quickly skip past.
☐ Interactive components are easily recognized as such.
☐ Interactions repeated from page to page are consistently presented.
☐ Clickable components are large enough to tap.
☐ Gestures and other movements requiring dexterity have alternative activations.
☐ Button labels are consistent with how they’re named in the code.
☐ Descriptive instructions are provided for complex forms or fields.
☐ Real-time and descriptive error messages are displayed along with suggestions on how to fix.
☐ Any checkbox, field, or other element in a form is tabbable.
☐ Checkout timers aren’t used or, at the very least, are set for a reasonable amount of time.
☐ Easy-to-locate language or country switches are present for international users.
☐ Your site or app is coded for speed. For websites, this may mean switching to a PWA depending on where your audience resides and whether or not they need offline access.
Domino’s may have thought it was doing a good thing by putting up a fight about website and mobile app accessibility. But all it really did was open a can of worms that can’t be closed back up.
So, there are two key takeaways here:
One other thing: Don’t let this be something that falls solely on your shoulders. Your writer and web designer (or developer if you’re a designer) have roles to play in bringing accessibility to your website or mobile app.
If you’re using a tool like Unite UX to collaborate with team members, make sure accessibility is part of the review and handoff process. It’ll make launch go much more smoothly.
A former project manager and web design agency manager, Suzanne Scacca now writes about the changing landscape of design, development and software.
Subscribe to be the first to get our expert-written articles and tutorials for developers!