Accessibility as you go: Part 1

Introduction and terminology

Earlier this year, I went to a tech accessibility event here in Minneapolis (sponsored by Clockwork and WeCO) that was incredibly enlightening. Participants got a chance to watch and ask questions as several users with different impairments interacted with websites: A blind man was visibly frustrated using a screen reader that kept getting trapped in a homepage carousel. Another user with low vision tapped at impossibly tiny buttons with a touch screen stylus. And a woman showed us an Active Braille reader with Active Tactile Control, which popped up Braille dots as she scrolled through and article (and a tiny tab actually pulsed like a cursor when she opened a new document.)

It’s important for us to witness these kinds of interactions to pry us out of our usability silos. I renewed my commitment to incorporating accessibility concerns into my daily routine. As many have pointed out, ALL users benefit from accessible websites, not just those with physical impairments. Voice-to-text, high contrast, and autocomplete are a few, classic examples of that principle.

So as we reframe our thoughts about accessibility from afterthought to integrated into the planning process, how can we as designers and developers anticipate and center accessibility in our work? In this short series, I’ll go over a few — surprisingly simple — things we can do to start incorporating accessibility work into the development process earlier, to save time and frustration at the end of a project, when it’s much harder to make universal changes.

First, some terminology:

A11y – This is an abbreviation for accessibility (A + 11 characters + y). This is a common hashtag on Twitter or used in accessibility technology, like Tota11y, which I mention below.

WCAG 2.0 – Web content accessibility guidelines created to set a baseline of accessibility for users all over the world. Content, in this case, refers both to the text, image and sounds, and to the underlying code and markup.

All of the topics addressed by WCAG have criteria for meeting Level A, AA or AAA (the highest level.) Level A criteria are considered absolutely necessary for modern websites; non-conformance to Level A standards means many users cannot access your site.

All websites should aim to meet Level AA standards — otherwise there are some users will experience some difficulty using your site. Considerations include contrast, text size, keyboard focus. Often, it is just a difference of degree from that which is required to meet Level A standards.

Level AAA is not required, but meeting it may improve user experience for some. A few criteria do make Level AAA difficult to achieve — for instance, sign language on all pre-recorded video. In many cases, reaching this level tends to depend more on the content producers than on the developers. Level AAA, realistically, is aspirational. It’s a goal to work toward — like, perhaps, just meeting the Level AAA criteria for contrast.

The United States government requires all nonprofit and government sites to adhere to Section 508. WCAG 2.0 standards are more up-to-date than Section 508 standards, and Section 508 is currently being revised to match WCAG 2.0 Level AA.

So, your first order of business should be to determine the level of accessibility your site needs (probably WCAG Level AA or AAA).

Next week, in Part 2, we’ll review some the tools you can use to easily find any problems before they get too big to easily fix, and some tips on when and how to test most efficiently.