It's very tempting to hand over responsibility over accessibility to other people. If you're a developer, it's the designer's job. If you're the designer, the developer needs to implement accessibility. If you're the product owner, it's the tester's job to make sure everything works with assistive technology. This is easy. Because if someone else accepts responsibility, then we're off the hook. I see two problems with this: 1. Someone else must always be willing to accept the responsibility In reality, this often leads to a situation where everyone assumes someone else is handling it, and accessibility falls through the cracks. When you don't take clear ownership, it becomes an afterthought or gets deprioritised until it's too late. Accessibility requires a shared commitment from the entire team throughout the product lifecycle. 2. You can't really pass responsibility for accessibility around Accessibility isn't a single task that you can neatly hand off. It's a core aspect of inclusive design that touches every part of the user experience. From conceiving the initial requirements to designing intuitive interfaces to writing semantic code. Trying to tack it on at the end usually creates lots of rework and leads to frustration and added costs. A much better solution is to willingly take responsibility. Here's the catch though. We cannot simply accept responsibility for our own small slice of the issue. In other words, if you're the designer, you can't just be responsible for colour contrast and then wash your hands of the whole thing after you hand it off to the developer. If you're a developer, you can't write the code to spec and not care about how it really works with assistive technology. You're a team, in the same boat and you will all go down with it, no matter where and when the holes appear. So better to work together to reinforce the boat lining and then plug any holes as soon as you see them, without throwing blame around. |
Join fellow like-minded product owners looking to learn and contribute to authentic conversations on accessibility and inclusive design packed into just 5 minutes a day.
Does this sound familiar? The meeting was scheduled for 9:00 but somehow at 9:06 Zoom still says "Waiting for host to start the meeting." When it finally starts, the organiser casually mutters "sorry, previous thing ran long" while fumbling with screen sharing. It's okay though, because they'll happily steal those minutes back by running fifteen minutes over the scheduled end time. Everyone waiting lost those first minutes. And everyone with a follow-up commitment will nervously look at the...
Accessibility. 13 letters. We thought it was such a lenghty word that we use the numeronym a11y to write it out. It has all these definitions floating around, each one just slightly different than the next. I think the reason why we can't settle on just one is simply because, like the word itself, accessibility is a loaded concept. It's just like a bulky piece of luggage you lug around and when you finally set it down on the floor and start to unpack, it'll likely fill the room. The...
Striking the balance between making the easy thing right and making the right thing easy in web accessibility is a crucial discussion. Do you choose the path of least resistance or fight through the discomfort and take the path of inclusiveness? The easy thing is copy pasting some code you found online. It might seem like the quick fix, but it often doesn't take into account the diverse needs of all your users. The right thing is making your website universally accessible. It involves...