Many people focus on just the development aspect of web accessibility. The truth is, a flawed design coded perfectly is just as bad as a brilliant design coded poorly. You need both aspects—design AND development—to truly succeed with accessibility.
A few months ago, I wrote a piece called “How to Ensure You Pay More for Web Accessibility Than You Should” and I noted one of the best ways to increase costs:
“Tell designers that accessibility is the responsibility of the developers and tell the developers that accessibility is the responsibility of the designers.”
Not only does this approach ensure that nobody is taking responsibility for accessibility, it’s actively a step further — saying “Not my job” is very different than saying “YOUR job.” When nobody takes responsibility for accessibility it ends up costing you down the road because you will need to change the design, retrofit, or otherwise compromise the accessibility of the work.
A lot of accessibility is straight up development
People almost ALWAYS feel that accessibility is something that is created programmatically, mostly in the domain of the web developer. And, in many cases, those pepole would be correct. There is a LOT that needs to be done programmatically to ensure that what you create is accessible to people with disabilities. BUT (and there’s a always a big BUT) – you can’t rely on programmatic accessibility alone.
Programmatic accessibility is what we need to provide for most screen reader users. But what about people that have low-vision? They rely on the visual aspects of a design to be able to perceive the design and make sense of the interface. What about people with cognitive difficulties, or language barriers? They need the visual aspects of a design to speak to them in a voice that they can connect with. There is a lot more to it than just programmatic accessibility.
And that’s where design comes in.
Accessibility is important in the design phase of a project too. We can usually predict areas of a design that will be a problem just by looking at wireframes, comps or even html-based prototypes. We look at the layouts, visual relationships between pieces of the design, information hierarchy, task flows and more. They give us insight into what is likely going to be a challenge for people with disabilities.
Ben Franklin supposedly quipped “An ounce of prevention is worth a pound of cure.” Truer words were never spoken when it comes to accessibility. Accessibility issues should be pointed out and addressed as early as possible in the design process. The longer you wait, the more costly it will be to change or fix later.
The bottom line is that a flawed design coded perfectly is just as bad as a brilliant design coded poorly. We need to have both for accessibility to succeed. For that to happen, you need to ensure that you’ve got accessibility taken care of as part of your process. As web pros, we follow a design and development cycle and hopefully we can integrate accessibility into several different phases: content planning, user research, wireframing, visual design, development and quality assurance. No matter what your process is, it is better to actually prevent accessibility issues from arising in the first place rather than trying to fix them later on.
This might sound like I’m saying “Design is more important than development!” but in reality, that’s the farthest thing from the truth.
It’s not about design OR development. It’s about both.
In order to be as accessible as possible, it has to be about BOTH. Design and Development need to come together to make for an accessible solution. They’re complementary. Like the Yin and Yang. Treating them as such helps ensure that we can build accessibility in to the process of creating whatever it is that we’re creating.
Over the past month I’ve been interviewed a couple of times. Some Yin and some Yang. Here they are — one is design centric, and the other is… (yes, you guessed it!) developer oriented. Give them each a listen. I think they’re worth it, but maybe I’m biased!
Accessibility as a Design Tool
Adam Churchill of User Interface Engineering (UIE) interviewed me for the UIE podcast Accessibility as a Design Tool. We talk about design, and accessibility and how we can use accessibility as to make designs better for everyone, as these improvements often lead to usability improvements to the interface for everyone.
I was interviewed by Chris Coyier and Dave Rupert in their front-end developer oriented podcast (ShopTalkShow). In Episode 58 of ShopTalkShow we get into some nitty gritty details of ARIA, why we need to ensure that we have non-ARIA based solutions, and why using lists for navigation is important. We’ve also made the Transcript for Episode 58 of ShopTalkShow available.
Think about your own practice — have you been overly skewed towards the development side of accessibility or the design side? How could you improve your work by ensuring your process includes more of BOTH aspects of accessibility? Would love to hear your thoughts, so please share!