Five Fundamentals of Accessible Responsive Web Design

What are the key techniques for building a responsive website that’s also accessible? I’ve been scouting the Web the last few days hoping to find clear answers to this question, but there’s precious little out there. You can find scads of great information about both accessible and responsive web design, but what about the intersection of the two?

The most frequent point is an important one – to wit, RWD (responsive web design) is a great entree into accessible web design. The two do have quite a bit in common. In particular, both depend heavily on adhering to standards. Related to that, RWD has emerged as the first popular venture beyond the stranglehold that desktops using Internet Explorer had on web design for over a decade. And accessibility is all about needs beyond “normal” desktop views of a websites.

I love this point. However, it’s not what I needed to know.

Rather, I was concerned that if you develop a site using standard accessibility and standard RWD, the latter would be fine, but the former might be compromised.

It turned out my concern was legit. However, it seems as if there are just a few straightforward things you need to pay attention to. For me, these boil down to the following.

1. Responsive, unlike accessible, requires all in

You can’t peicemeal responsive. If you can’t do all of the major pieces explained by Ethan Marcotte in his seminal article on RWD together, it’s better to wait — particularly if you want the site to be accessible. In other words, save responsive for a redesign or a site facelift. With accessible code, on the other hand, while it’s best to get as much done initially as you can, there’s so much to it that a partial effort is considerably better than none at all.

2. Don’t code responsive images until you have a wholly responsive site

This is actually a specific part of the first point. However, since it’s a rabbit hole I’ve gone down, I thought it worth being explicit. At the very least, rendering images responsive in a site that’s not otherwise responsive makes for deceptive desktop testing. However, my real concern is it can have accessibility ramifications that aren’t worth the time to test and untangle.

3. The viewport must permit zooming

There’s much debate in the RWD community about how best to code the viewport. However if you’re committed to an accessible site the answer is clear. Do not add parameters like “maximum-scale=1.0” or “user-scalable=no” to the content attribute. In other words, optimal RWD code looks like this:

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

The end. Period.

By the way, the reason developers add code such as “maximum-scale=1.0” is that without it on some smart phones a switch in orientation causes the layout to go haywire. As someone with one of those phones, I hear the developer pain behind leaving this code off. But it’s simply bad accessibility ju-ju to sacrifice zooming — and hopefully over time all of the major vendors will address this issue at their end.

4. Extra credit: use em or % for layout, not pixels

I think this one may be less critical. However, George Zamfir has the best overall information I could find on accessible RWD, and he recommends it. I, in turn, recommend reviewing the slideshow from his most recent presentation: Responsive Web Design – An Accessibility Tool (The Accessibility Conference in Guelph, May 29, 2013).

5. Test carefully

Of course, right, but….

The thing is it’s not easy to figure out what to test without completely and utterly bogging down. And my hunch is this quagmire is one of the main reasons many awesome web developers shy away from accessibility. In this perfectionist bog, not only do you never get the thing finished, you never want to bother with accessible code again. But good news…. Henny Swann has created a first-rate list at Mobile accessibility tests. It hits the sweet spot someone like me needs — with a list that’s carefully crafted, but not debilitatingly exhaustive.

So that’s what the accessible RWD landscape looks like to a front end developer like me. I’d be most grateful if those who know more about this topic than I would tell me if I’ve got this right or if I’m missing something.

10 Responses

  1. Great post, Anna Belle! Refreshingly straightforward description of your search for answers regarding RWD and accessibility, with links to excellent resources you found. Bookmarked!

  2. Thanks, Paul! So far none of the a11y gurus have said I’ve gotten this wrong, so maybe I made an accurate dent in this little corner of the universe.

  3. Nice post Anna – and some useful links. I was wondering if you could amplify further on the accessibility ramifications you mention in point 2 – I’m not quite sure I understand the a11y issue there.

  4. Well said on the zoom, I’ve had developer battles over that, originating from the orientation bug but with the argument that ‘designers can just set an appropriate text size’. It’s really not rocket science to understand that there is no appropriate text size. Especially in responsive, where someone with perfect vision may need to zoom due to direct sunlight, phone in power saving mode etc.

  5. Although actually some more explanation would help, as you’ll have people with no prior experience reading this. Instead of ‘bad accessibility juju’ say that it prevents people with mildly impaired vision from being able to zoom the text up to a size that they’re able to read.