Developing with ADA in Mind
In previous blog posts, we’ve talked about the importance of making your website ADA compliant. In this article, we’ll be delving into what it is like to develop an ADA compliant website. This blog post will touch on some of the more painful and time-consuming issues we’ve faced while working with AA-level ADA requirements.
Though the title of this blog post is “Developing” with ADA in Mind, I think everyone (designers, project managers, etc.) who are considering making their websites ADA compliant should be aware of these pitfalls.
Following ADA requirements isn’t as simple as adding aria-labels, alt text, and other minor HTML tags. In fact, compliance requires a good bit of initial planning followed by ADA-focused implementations and architectural choices before and throughout development.
Solutions for ADA Compliance
The webpage is not navigable with a keyboard
A user should be able to get through the entire website by tabbing. This includes simple elements such as links and buttons, but it also includes incredibly complex elements such as a carousel, tooltips, modals, etc. While most browsers have built-in rules for focusing and navigating to buttons and links, they often don’t cover complex components, especially ones that are JavaScript-heavy.
Let’s take a tooltip, for example. Normally, a user would be able to get additional information by hovering their mouse over a specific word. However, this is not ADA compliant as such information wouldn’t be available to those who tab over to it. A simple ADA compliant solution could be the following:
HTML
<a class="tool-tip" href aria-describedby="tool-tip-1">
Here is a tooltip:
<span id="tool-tip-1" class="tool-tip-hover" role="tooltip">
Some tooltip information here.</span>
</a>
CSS
// A bit of style has been added to make the button and link less awful.
.tool-tip {
padding: 5px;
border-radius: 5px;
color: #000;
position: relative;
}
.tool-tip-hover {
display: none;
position: absolute;
left: 0;
color: #050709;
background-color: #6aaace;
padding: 5px;
border-radius: 5px;
}
.tool-tip:hover .tool-tip-hover, .tool-tip:focus .tool-tip-hover{
display: block;
}
But, what if more requirements are added? What happens if someone wants to add a close button on the tooltip that a user could tab to and press enter to close the tooltip? What if the tooltip has a link that goes to another tooltip? Then, this simple CSS hover and HTML aria-label trick won’t cut it. An approach using JavaScript or some sort of library might be necessary.
Often times, customers will ask for additional functionality to be added so that it does more than just show information. Unfortunately, additional functionality could mean a lot more development time, and possibly even a redesign of the existing component.
We dive into ADA web compliance for digital commerce with ADA experts on Blue Acorn iCi’s The Funnel: An Experience Driven Commerce Podcast. Listen here.
The webpage cannot be zoomed
This is an issue commonly seen in multi-panel apps because you want to keep the page looking exactly like the design.
For a website to meet the AA standard, a user should be able to scale the page up to 200%. While this might seem trivial, we have had issues where the requirement was to keep a certain ratio or certain design for the web page. In order to achieve a uniform look throughout, some may set the width or height at 100%. This means that no matter how much you try to zoom in, the page will look exactly the same.
However, this doesn’t mesh with a responsive site. You need to know that your lower-res styles will show through in some cases (e.g. 200% zoom on desktop may trigger mobile styles). While this effect of a lower-res style does not affect ADA compliance, some people might find it really, really annoying because depending on the design, the locations of form elements, buttons, etc. could change, forcing the user to chase down where they went.
Even if your website does zoom, you have to make sure that all the elements do not overlap, overflow out of their respective containers, or have any other unwanted side effects. An example of this we found in the wild is at CSS-Tricks (left). Unfortunately, solutions to this problem vary widely, especially if there is certain design or look that needs to be maintained. One of the more common fixes we’ve suggested in the past are changes in layout (e.g. change from 3 column look into a 2 column look at lower screen width), or have less content.
Color contrast is not high enough
A company’s style guide will oftentimes define the color to be used for branding and require that the site complies with its standards. But as a developer, it’s important to convey that it might not look the way marketing wants because ADA requirement specifies that “level AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Level AAA requires a contrast ratio of 7:1 for normal text and 4.5:1 for large text.” In other words, the exact color, font, or text size that marketing specifies may not be ADA compliant and the developer will need to make some adjustments. Having that understanding upfront can save a lot of headaches along the way.
Changing a color to another color, one that would more closely match the branding, might not take very long. In fact, it might be a single line of code that needs to be modified. But, the scary pitfall with this particular issue is the time it can take to regression test the change. This is especially true if the color in question is used widely throughout the website. Let’s say you have an about us page such as this:
While the designs may look neat, the yellow submarine in the picture above doesn’t have a high enough contrast between it and the sea behind it. To solve this issue, let’s make it darker:
Though the submarine is darker, the color change is affecting other parts of the page. For example, the color contrast between the words “Meet the Crew” and the submarine isn’t high enough. In order to achieve ADA compliance, many more changes to the initial designs would need to made. For example:
A small color change can affect so many aspects of the website, especially if you use SCSS or LESS variables. It’s imperative to pay close attention to contrast standards and work with marketing to find a value that works for branding and compliance. There are a lot of resources out there that will help you determine if a particular combination is ADA compliant.
There are multiple variables that need to be thought through regarding ADA compliance when the site is actually being developed or updated. But, this shouldn’t discourage people from making websites ADA compliant, as there are so many reasons to do so. Just remember, the sooner the requirements for ADA are internalized, discussed, and planned for, the smoother the development will be!
If your site needs an ADA audit, we can help! Reach out to us today to get started.