Considering that an estimated 20% of the population have some type of disability, accessibility compliance isn’t just a legal requirement–it’s good business. The Americans with Disabilities Act prohibits discrimination against people with disabilities and when it comes to the web, ensures that website accommodations to provide access to people of all abilities are made. All federal institutions and private sector businesses with 15 or more employees need to meet the web accessibility guidelines in the ADA.
But is your website’s design ADA compliant?
In this quick reference guide, we’ll learn more about what ADA is, why accessibility matters, and how you can approach web design with ADA compliance in mind.
What is ADA?
The Americans with Disabilities Act legislation came into effect in 1990. Of course, the Internet was in its infancy, as this was the very year that Tim Berners Lee invented the World Wide Web. Title III, the section relevant to private sector companies, was last updated in 2010.
The Design Standards you’ll see listed on the ADA website apply only to the physical world. These are the guidelines for construction, alterations, paths of travel and more that dictate how we make all kinds of public spaces accessible. Wheelchair ramps, doors that open automatically, and Braille on signage and doors are just a few examples of real-world accessibility accommodations.
How is the Web Made Accessible?
Interestingly, the ADA doesn’t specifically pertain to websites. Instead, the legislation reads:
“Although the language of the ADA does not explicitly mention the Internet, the Department has taken the position that Title III covers access to Web sites of public accommodations. The Department has issued guidance on the ADA as applied to the Web sites of public entities, which includes the availability of standards for Web site accessibility… Additional guidance is available in the Web Content Accessibility Guidelines (WCAG).”
WCAG are the Web Content Accessibility Guidelines developed and maintained by the Web Accessibility Initiative, a subgroup of the World Wide Web Consortium (W3C®). The most recent version, WCAG 2.1, covers a wide range of recommendations for making the Web more accessible, from text alternatives to using distinguishable elements online to navigation and more.
For example, an accessible site should be navigable and fully functionable by keyboard only. Each site should also be supported by assistive technology such as screen readers, screen magnifiers, and speech-to-text software. The site must also be able to handle text scaling of up to 200%, without requiring horizontal scrolling or content-breaking layout. Further, sites should be accessible on all digital devices, including laptops, desktops, tablets and mobile phones.
Common Website Accessibility Issues
Although each of the recommendations is important, some accessibility issues have proven more pervasive than others.
Images without text equivalents are problematic on a number of fronts. Accessibility aids such as screen readers and refreshable Braille displays need alternative text on images in order to read the content to users. Further, search engines use alternative text on images to determine the content of each one and its relevance to the queries of each user. Make it a best practice to use HTML to provide descriptive text for each image and graphic as it’s uploaded to the site. You can use the “alt” tag for small amounts of text, and “longdesc” for longer blocks.
Documents not posted in accessible formats are another common issue. Image-based formats like PDF can be inaccessible to people using screen readers or text-enlargement programs. What can you do? Be sure to provide text-based format documents like HTML or RTF (Rich Text Format) in addition to your PDFs.
Different color and font settings on various computer displays can also render such content unreadable or inaccessible. Some sites are designed so that changing color and font settings is impossible. Low-vision users need the ability to manipulate color and font settings in browsers and operating systems to make pages readable for them. You can prevent this becoming an issue by designing sites so low-vision users can specify the text and background colors and font sizes needed to see page content.
Videos and other multimedia can also prove challenging for users of differing abilities. Those who are deaf or hearing impaired may not be able to hear the audio soundtrack, while visual impairments interfere with a user’s ability to view the imagery of the video. It’s critical that you add closed-captioning for the hearing impaired. You can also provide audio descriptions of images, changes in setting, gestures and other visual cues, for those with visual impairments.
Considerations for Successful Accessibility Compliant Web Design
As a first step, meet with the entire project team and review accessibility standards. Discuss how accessibility standards apply and relate to the product being built, to ensure everyone is on the same page. Determine the level of conformance needed, exactly which guidelines must be implemented, and how your team will comply. Agree on which tools you’ll use to automate checks as early as possible, and whether you’ll require some level of manual testing, as well.
Accessibility compliance is a team effort, so including it in all aspects of each role in the creation process is key.
User stories and requirements should be written in ways that reference accessibility standards where applicable, for example. Requirements are created by way of user stories when we apply Agile methodologies to design. These are essentially the written blueprints for the system or product you’re building, and typically follow a specific format that you can read about here.
Design with accessibility top of mind. Designers should be aware of the ways in which their designs and user experiences impact users with accessibility needs. You can use resources like Tips On Designing For Web Accessibility and WCAG 2.0 Guideline 1.4: Understanding Distinguishable to create experiences that conform to accessibility standards and expectations.
Check your code. Developers can utilize linting tools like Eslint-plugin-jsx-a11y or aXe-Core to check their code while being written. This ensures that basic needs are met before even being deployed for testing.
Automated quality assurance can also incorporate accessibility testing tools into the automated tool of your choice. See this resource on GitHub to get started.
Manual quality assurance can fill the gap left by development’s linters/CI tools and automated QA tools. This is another area where aXe: The Accessibility Engine and Lighthouse come in handy (you’ll learn more about these below, in testing). Manual QA as a function of the design process can check for things that automation cannot by employing tools like screen readers and tactics like keyboard navigation. Additional plugins and tools are available.
Site Accessibility Test Tools
With the full set of WCAG 2.1 guidelines at hand during development, how can you then test to ensure ADA compliance prior to launching?
Manual accessibility testing can help identify issues with content using screen readers, speech recognition software, speech-to-text software and more. A subset of usability testing, accessibility testing is offered by many firms–so many, in fact, that you’ll need to do due diligence to ensure that your testing firm of choice is fully knowledgeable and qualified to suss out any issues. Considering the potential legal implications of failing to provide an ADA compliant and accessible web experience, it’s well worth making sure you have the right people testing for compliance.
Automated testing software like open source Lighthouse can run audits against any web page, whether public or requiring authentication. Provide a URL to audit and a report is generated with indicators to help you improve the accessibility of the page. Developed by Google, Lighthouse runs from Chrome DevTools, as a command line, or as a Node module. You’ll find a step-by-step guide on how to use it here.
Wave Web Accessibility Eval first launched in 2001 and as such, is one of the longest-standing accessibility testing tools on the web. According to its developers, Wave has been used to test the accessibility of millions of web pages. It’s available as a Chrome or Firefox browser extension, or in a variety of site-wide formats including an API.
Open source aXe, on the other hand, is a set of accessibility testing rules designed “to empower developers to take automated accessibility testing into their own hands and to avoid common pitfalls of other automated accessibility tools.” There are no outside server calls required, it integrates with all modern browsers, and you can create custom rules, if you choose.
Want to learn more about accessibility compliance? Get in touch with Method to see how we can work together to make your project a 100% ADA compliant success.