Getting Started with Front-end 508 Compliance

In my current role as a front-end engineer, Section 508 has become a driving force in some of my work. Since my company does business with the U.S. government, we’re required to meet a level of accessibility that ensures users with visual disabilities can interact with our web properties.

Most, if not all, developers and designers dread Section 508 compliance. Oftentimes, it means combing through our interfaces using unfamiliar tools to make sure people we’re not even sure exist can use our software.

This is a cynical mindset, of course—because those users do exist and they have real disabilities that developers and designers must take into consideration. Can you imagine if buildings were not required to support wheelchair-bound patrons or if crosswalk signals did not incorporate auditory features?

The web is not dissimilar to the physical world. Websites must operate in a fashion where people of any ability can achieve critical tasks. For me, this meant ensuring users could access online verification tied to the U.S. Department of Veterans Affairs’ new services portal.

In implementing and improving the 508 compliance of our technology, I learned a few good lessons, which I share below.

Know what you need to support

Section 508 seems straightforward on the surface, but it’s actually a long, thought-out law. Disabilities extend beyond visual to include physical, cognitive, and auditory impairments.

For most front-end engineers, the visual side of the law is most important. This means everything transmitted from the screen to the user should be scrutinized as if the user was color blind, partially blind, and fully blind.

And while private and commercial websites are not held to 508 standards, it’s still good practice to put together at least a basic plan to support these users.

Test, test, test

The biggest challenge to 508 compliance is testing your enhancements. Users with disabilities access tools that the general population has never had to install. The most complicated of these tools is the screen reader.

A screen reader is simply software installed on the user’s computer that dictates what’s happening on the screen. Through various keyboard commands (which are sometimes complex), the user interacts with websites. This includes everything from navigating through a site’s menu to reading descriptive text to filling out a form.

Testing screen readers offers limited options. Fortunately, macOS comes prebuilt with VoiceOver, which is available via the Accessibility Tools in System Preferences. The software is generally easy to use but does feature keyboard commands that require a lengthly manual.

Freedom Scientific’s JAWS for Windows is also a big player in the screen reader market. It’s also pretty expensive. You can download the software package for free, but it operates in 40-minute blocks, requiring you to restart Windows. This may seem like too much of a hassle, but I highly recommend testing against JAWS as this is the software I’ve seen much of the U.S. government implement in their own offices.

Understand what HTML tags are necessary

The ARIA attributes were invented specifically to help define web content areas for people with disabilities. These tags are easy to add, well-documented, and can really benefit your users.

Knowing when to use these attributes will save you time. When using a traditional HTML element, such as form tags, there is no need to use ARIA attributes. These attributes are reserved for the cases when you’re outfitting a non-specific element to serve as a functioning element; for example, if you’re using an unordered list to make a select box, then you’d use the listbox and option roles along with the aria-activedescendant and aria-selected attributes. Read more about this specific example here.

There are also important ARIA attributes that enable the user to perform important content actions, such as being notified of live updates or hearing the navigation structure.

Using a screen reader to test your website will make it clear where your accessibility is failing.

Color contrast is important 

Often overlooked in 508 compliance is the need to adopt a color scheme that is contrasting enough for visually impaired users. This means overlaying text should be readable against its background.

The biggest issue I’ve run into with this requirement is the design challenge. WCAG 2.0 AAA standards require a 7:1 ratio for color contrast which essentially results in two starkly different colors. For designers, this makes accent coloring near impossible.

There are some methods to overcoming the contrast design issues, such as using box shadows or borders, but at the end of the day, it becomes a compromise between design and usability. For my team, we’ve decided our core, government-dependent components must meet WCAG AAA standards for every element, from form fields to buttons. However, for our business and consumer facing properties, we focus contrast compliance mostly on actionable elements. WebAIM has an excellent tool for testing foreground and background colors to see how they stack up against both WCAG 2.0 AA and AAA requirements.

Find users with disabilities

Operating a screen reader is a foreign experience for me. I’ve never relied on one consistently, so it’s always new territory for me. The commands are odd, the narration cumbersome, and the reliance on the keyboard different from my normal computer interactions.

With my inexperience, I often stumble around with the screen reader to get a basic understanding of how it interacts with the pages I’m testing.

This is why testing your websites with users who have real disabilities can be enlightening.

I had the opportunity to go step-by-step through a form flow with a member of a government 508 department. He had a visual disability and depended on his screen reader to navigate the web. As he went through the flow, I took note of how easily he commanded the screen reader, how he sped up and slowed the narration as needed, and how quickly he was able to move up and down the page with different keystrokes.

His experience was completely different from mine, and I learned first-hand how people actually use screen readers and where the biggest stumbling blocks existed in the flow.

Finding disabled users may not be easy, but if you have access to a family member or friend with visual impairment, it could be a great start toward seeing the real problems with your application’s 508 compliance.

Make it part of your quality assurance

Achieving 508 compliance should be rolled into the front-end development process similar to other core tasks. If your process includes testing new features with the QA department, then they should also test the 508 components of that feature (or, if you’re lucky, you may already have a dedicated 508 department in your organization that can test).

My team does limited 508 testing with the screen reader, and having a second set of ears has helped me to uncover bugs. Training and assisting the QA team is an effort you need to lead—become a champion of 508 in your organization and ensure all of your users can access and interact with your applications.

Other great resources and tools

Below is a list of the tools and websites I rely on for 508 compliance learning and testing. And, coincidentally, a great article from CSS-Tricks was just published covering some of the tactics a UI designer can employ to build more accessible websites.

See more posts