Web Accessibility: transitions and process

Important accessibility details get lost in the handoff from design to code. The fix is mixed-role conversations, not more meetings.

Last week I had the privilege of speaking at John Slatin AccessU in Austin, Texas. I gave presentations in both the Design & Usability track and the Development track, but the reality was that most people that attended sessions had a very diverse background. In the Designing Interactions talk (which was in the Development track) we had developers, designers, UX people, project and product managers. That was most pleasing. After all, accessibility is everyone's responsibility.

When we were doing group exercises, I encouraged participants to talk about the problems we were trying to solve with someone that wasn't the same as them. In other words, developers talk with designers, or content people talk with product managers, or some other combination. But no groups should be just designers, or just developers or just any one role. Why?

Web people don't talk enough. Yes, I know — we all want to have fewer meetings. Actually, I think we all just want fewer meetings that aren't productive or are seen as a waste. But good, productive meetings? I'll take that any day.

Something weird happens when we take a design and implement it in code. Important details are either Lost in Translation or are never even discovered.

A design is often created with some very specific accessibility considerations in mind and the designer doesn't provide some of that detail to the development team. And then, the overworked developer passes those on to an overworked development team. And some of those details are lost.

This post has been lightly edited. Originally published at https://simplyaccessible.com/article/web-accessibility-transitions-process/

(No Wayback snapshot of the original page is available; outbound links updated to working archives where the originals 404).