Designing for ADA Compliance

Sometimes it’s what you don’t see on a website that’s most important.

In September 2010, the Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design, requiring businesses to ensure that all of their customers have access to the same services, regardless of their physical limitations. Equal access laws previously applied only to physical locations, but as digital has evolved, the DOJ has encouraged organizations to follow WCAG 2.0 level AA guidelines to ensure accessibility for websites and mobile apps. In fact, online ADA compliance has become more prominent over the years now that more than 240 businesses across the country have been sued in federal court over website accessibility since the beginning of 2015.

When the Ohio Secretary of State took on the task of updating their website for ADA compliance, they turned to Hanson. While our job usually involves making a site look better visually, in this case the assignment was making mostly behind the scenes updates to ensure it met accessibility standards.

We sat down with Kelsey Lortz, Solutions Architect, and Brian Thomas, Front End Developer, to talk about how they and the rest of the Hanson team worked together to solve the unique challenges of this project.

When you first began this project, what were some of your immediate considerations?

Kelsey: We design and build sites always with the final users in mind, which of course includes those with disabilities. So it’s important for strategists and developers to take ADA compliance into consideration when they make updates to—and especially when launching—new sites. But one complication is that ADA compliance is an evolving definition; meeting certain guidelines for one set of users may create a worse experience for another. It has to be done carefully, and the WCAG guidelines are helpful.

So first, we needed to know specifically what guidelines we were adhering to and define how we might adjust our usual process for planning the site, building it, and performing QA testing. Ohio Secretary of State was charged with meeting WCAG 2.0 A and AA standards, so we reviewed this and asked questions like:

• How many iterations should we have, and what kind of testing should we perform after each?
  
• Do our developers need to build using different methods than normal?
  
• What screen readers should we use to test for compliance?
  

Brian: We also collaborated with the accessibility expert for the Ohio Secretary of State. He helped us understand what some of the roadblocks to accessibility were on the current website. One immediate concern, for example, was how the current site worked on screen readers for those with vision impairment.

Kelsey: Yes, and while this site did not have a lot of complex functionality, a couple components like a homepage rotator and a Twitter feed required research and rounds of testing to align on an adequate solution. They also had a surplus of data tables, some of which had more than five hundred rows. Imagine a screen reader going through those and it’s easy to get lost without the adequate code on each cell that ties it to its row and column.

Once you determined some of the immediate needs, how did you define our approach?

Brian: We used a number of scan tools such as SortSite to help diagnose most of the accessibility issues, giving us a good starting point. The scans grouped accessibility issues by level of importance, with level 1 being the highest and level 3 being helpful but not completely necessary. We made priority 1 and 2 of utmost importance, and also fixed a variety of level 3 elements we felt were important. And we had to ensure that when we fixed one issue we were not creating other issues in the process.

Kelsey: During production, we continued to consult W3C for best practices in building components that were compliant. We consulted with the client’s accessibility expert on priorities. After each iteration, we also layered into our normal QA process both automatic testing (using scan tools like SortSite that test for WCAG 2.0 compliance) and manual testing (with screen readers on multiple devices like NVDA on Windows).

Brian: Checking screen readers was important for understanding the flow of information for the listener. If it repeated information or didn’t flow in a logical order, we went in and adjusted the code to compensate until the experience met our performance standards.  

The greatest challenge by far was dealing with the existing table structures. A compliant table needs to have a certain structure for screen readers to make sense of the data they are reading. So we put the necessary html attributes on elements to help screen readers make sense out of what they were running through. Because of the setup of the tables, we couldn’t programmatically fix all the issues using a find and replace functionality. It was a manual process which took a lot of manpower to fix. In the end, due to the amount of data in the tables and the amount of tables on the site, we ran into some limitations. But we did make improvements and, more importantly, gave the client the tools and know-how to format their table structures in a more compliant way going forward.  

How does ADA compliance affect the visual design of a site?

Brian: On the surface, a standard user without disabilities won’t notice many visible changes to the functionality of the site when ADA compliancy changes are made. Most, but not all, compliancy fixes take place behind the scenes in the code and affect interactions with different tools. Simpler is generally better in terms of compliancy.

But one good example of how ADA compliance affected the design was on the homepage. Initially the site had an image carousel that cycled through news items but it was unusable because of how the screen reader interpreted it. We initially attempted to make the carousel compliant but eventually decided to create an alternate layout of the homepage which would allow for all content to be visible, unlike carousels which hide certain content until coming into view. Not only was this better for the logical order of screen readers, but it also allowed all users to quickly scan the page and find what they were looking for without having to cycle through content and potentially never even see the news they were seeking. The client was pleased with the resolution of this design and compliancy issue.

Kelsey: Another example of designing a site for someone who is visually impaired is how we rethink the standard ways of indicating links or other places to click. Using a different color for link text doesn’t accommodate colorblind or fully blind users.

Brian: You really have to put yourself in the mind of the user to adequately solve their challenges. For example, we used one tool to help us understand how a color-blind individual may experience the site. It was quite an experience viewing the site from this vantage point! Some website elements would sort of fade away and make them difficult to see if the contrast ratio was not high enough. So we used another tool to check the color contrast ratio to determine if it was adequate.

Kelsey: In the end we used a combination of things like text underlining and info in the code for screen readers to ensure the design worked well for everyone.

What advice would you offer to a business embarking on ADA compliance?

Kelsey: Digital practices and how we create digital experiences are constantly in flux. The WCAG standards are regularly re-evaluated, so what’s legally compliant today may not be in so many years. How we build to be compliant will change as a result.

But you can start with an audit to see where you are not being compliant today. Review the results and consider why you are looking to become ADA compliant. Are you legally required to do so, and at what level (A, AA, AAA)? Are you just looking to create an experience that caters to all users, including those with disabilities?

How far you are willing to go to meet compliance will determine how you prioritize the fixes an audit recommends. Ideally, all sites would be compliant. It can be a minor to a major project to redesign and rebuild components of your site, so choose carefully what you take on, and when. But moving in the direction of ADA compliance is a wise path forward both legally and ethically.

Brian: Definitely do your research. I don’t think most organizations realize that 19 percent of the population (approximately 56.7 million people, according to census.gov) have some form of disability. Compliance can be a big undertaking, depending on the size of the site, but in the end it will pay off. And I’m certain that those individuals who can now access your site as a result will be very grateful that you chose to do so.