I walked into my office this morning and felt a pang of tension. The craziness of the previous afternoon had allowed me to forget what was sitting on my desk. But it was still there. Printed out, highlighted, underlined, corners folded...
I’d heard the word “lawsuit” many times before but somehow never thought of it as a physical object, something I could hold in my hand. Trust me, if I placed it in your hands, you’d swear it was heavier than it should be. Heaviness is more than the numbers—these pages have a different kind of weight to them. And this lawsuit is not for us or any of our clients. It was passed to me by an organization being sued because their site is not accessible. They’re asking for help and they’re not sure what to do. This kind of suit has been happening for a while now, but many of us haven’t really been paying attention. We are unable to truly pay attention until it affects us or someone close to us.
Recently, a few Sparkboxers had the chance to attend web accessibility training in Utah. Since their return, they’ve been sharing much of what they learned. One of the bits of knowledge they came back with has stuck in my brain the past few weeks. It’s the first rule of ARIA: “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.” Start with good, clean, HTML and you’ll be well on your way to an accessible experience. If you read on, one of the reasons you might stray from using a native HTML element is “if the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.” It’s our attempt to control the experience that leads us down a path of inaccessible products.
Jeremy Keith saw this 12 years ago. “Far from being something that is added to a site, accessibility is something we need to ensure isn’t removed,” he wrote. It’s the same story. When you strip away all the stuff we do to try to control the experience of a website, it turns out the web is pretty darn accessible. It only breaks when we break it.
This is true with accessibility, but it’s also true with responsive design. When you strip away all the stuff we do to try to control the experience of a website, it turns out the web is actually pretty darn flexible. Text will reflow beautifully—in fact it will fit on any screen you throw at it—until we start fixing widths.
Please hear that I’m not saying we should strip our work of design and interaction. But I desperately want us to prioritize accessibility as a fundamental value of the web over an inaccessibly designed experience. We need to strengthen our sensitivity toward going against the grain of the web.
Sparkbox chose to embrace responsive design early after reading Ethan Marcotte’s original article explaining the technique, because we saw it as a step toward building a better web. It was a chance to make the content we were sharing through our work on the web accessible to people, regardless of the size of their screen. Responsive web design is about accessibility.
The pages of that lawsuit are heavy because they represent real people—people who want to be customers, who want to engage with a brand. Instead, an inaccessible experience turned them from potential customers into legal adversaries. All because folks didn’t understand that, like Jeremy Keith wrote, “accessibility is something we need to ensure isn’t removed” from a web experience.
I recently asked a friend who happens to be blind if he’d share some sites that were built really well—sites that were beautifully accessible. You know what he said? “I don’t use the web. Everything is broken.”
Everything is broken. And it’s broken because we broke it.
But we can do better. There are some great resources out there. Start by getting comfortable with the WCAG. Go into this knowing it’s not just for developers. Designers need to design with accessibility in mind. Authors need to write accessible web content. And everyone needs to learn how to test for accessibility.
This is really about choosing to work with the grain of the web. It’s about keeping the web accessible, not making it so. And once you have the mindset in place, the tech will follow!
If you don’t know where to start, we can help. Answer four quick questions and get an estimate for your web accessibility audit.
