I originally wrote the following post back in May, 2016, but it never made it out of my drafts folder. Since then, my teammate Jared has gone on to serve the American people at the United States Digital Service and Groupon acquired LivingSocial. Quite a lot can happen in six months, right?

On to the original post…

At work, we’re in the thick of rebuilding several of the key pages in our Restaurants Plus product. The team’s making great progress building out a mobile-first, responsive, progressively-enhanced website while concurrently developing a reusable pattern library for future development (and future teams). I’ve particularly enjoyed the challenges of building out the updated “explore” page: a JavaScript-heavy page listing the participating restaurants in a metro area that’s filterable, sortable, and very dynamic.

There are a handful of lessons I’ve learned around writing high-performance, low-overhead JavaScript that I hope to cover in future posts, but for today, I’d like to share a few quick things that Jared and I did last week that improved accessibility in meaningful ways.

A Few Caveats…

First, I don’t self-identify as an accessibility expert (few do, in fact). I’m merely a for-now able-bodied front-end developer with an interest in building products accessible to all. I’ve also had the good fortune of learning from local accessibility guru John Croston and other accessibility advocates like Derek Featherstone, Aaron Gustafson, and Marcy Sutton. We all benefit from the open sharing of knowledge on the part of the Web accessibility community.

Second, the changes outlined here are what I’d consider low-hanging fruit. Simple webpages often require only simple updates to improve their accessibility. More complex pages (like the “explore” page referenced above) naturally require more complex code to provide an accessible experience. My goal with this post is to demonstrate how even small changes to a page’s design and code can yield quick accessibility wins.

Third, accessibility is a practice and requires consistent attention over a project’s lifetime. You never really cross accessibility off of your project’s to-do list, just as you wouldn’t treat performance as “done.” That may seem daunting, but it’s a good thing for your customers, your team, and your business.

Tools and Guidelines

There are a number of tools for testing a website’s conformance with Section 508 (a U.S.-centric accessibility standard) or the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0. The browser bookmarklet HTML_CodeSniffer is a personal favorite, but there are other useful tools available:

• pa11y: an automated accessibility testing tool available in several flavors.
• Tenon.io: a hosted automated accessibility testing tool.
• tota11y: an accessibility visualization toolkit from Khan Academy.

These tools make objective evaluations of your website’s accessibility against known standards and should be supplemented by real user testing to determine the practical accessibility of your website. You could conceivably design and build a website that passes WCAG 2.0’s AA compliance level but that has inaccessible complex interactions. So: keep in mind that automated accessibility testing is a starting point.

Small Changes, Big Improvements

For the purposes of this post—and to demonstrate the utility of automated testing tools as a starting point—I used the HTML_CodeSniffer bookmarklet to check against WCAG 2.0’s AA compliance level. Running HTML_CodeSniffer on the aforementioned work-in-progress “explore” page yielded a high number of conformance errors and warnings. Paging through the results, I found the most common error had to do with insufficient color contrast:

This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 1.53:1.

The element in question appears throughout the UI and contained white text (hex triplet #fff) on a light grey background (#d1d1d1), which is quite difficult to read and clearly lacking contrast. Working with the design team, we iterated on the design and decided on dark grey text (hex triplet #666) against a light grey background (#e6e6e6), giving the element a color contrast ratio of 4.6:1. Success!

The next error was similarly easy to identify and resolve:

Anchor element found with a valid href attribute, but no link content has been supplied.

In this case, the element in question is the site’s navigation control, commonly known as the hamburger icon. The markup looks something like this:

<a href="#site-nav">
    <svg><use xlink:href="#sprite-hamburger"></svg>
</a>

We’re using an SVG icon sprite (which I’ve written about previously) to manage our website’s icons and the pattern above references an icon with the <use> element.

<svg style="display: none;" version="1.1">
    <symbol id="sprite-hamburger" viewBox="0 0 22 16">
        <title>menu icon</title>
        <path d="…">
    </symbol>
    <!-- additional <symbol> elements here… -->
</svg>

As is good practice, the SVG <symbol> representing the icon has a child <title> element with descriptive content of “menu icon.” Since the SVG contained a meaningful <title> element, I was initially confused by the reported error. I checked the page with VoiceOver and confirmed that “menu icon” was spoken aloud indicating that, in an indirect way, the anchor element had content that would be read by the screen reader. (I’m unsure if this is a shortcoming of the conformance parser or a genuine error. Any thoughts, accessibility friends?)

Regardless, it’s easy enough to add meaningful content to the anchor:

<a href="#site-nav">
    <svg><use xlink:href="#sprite-hamburger"></svg>
    <span>Site Navigation Menu</span>
</a>

We can then use CSS to move the <span> out of the viewport while leaving the element perceivable to assistive technologies. In my testing, VoiceOver read “Site Navigation Menu,” preferring textual content in the HTML over the SVG’s <title> element.

Accessibility is never “done”

The changes outlined above—which took very little time and effort—greatly reduced the number of WCAG 2.0 AA errors and warnings reported by HTML_CodeSniffer and meaningfully improved our pages’ accessibility. Our work is far from finished, though.

As mentioned earlier in this post, accessibility is never “done” and must become an integral part of an organization’s design process. Likewise, automated evaluation and testing tools like HTML_CodeSniffer serve as a great starting point, but should be augmented with real user testing to ensure that a website’s design and buildout are accessible to all.