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.
Too much baggage
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 overwhelming number of concepts, rules and tooling available today might give you the impression that accessibility has gotten perhaps too complex. We have guidelines, laws, compliance, ARIA patterns, procurement requirements, third party tools, population statistics and a bunch of people yelling at us we need to be accessible. It's no wonder whenever you hear accessibility you roll your eyes and think it's not your job. Designers shout at developers when they go rogue and start slapping divs left and right forgetting about proper semantics. The developers fight back and blame the designs with all the bells and whistles, visually stunning, but practical for people with disabilities? Not so much. And by the way, aren't the testers responsible for how the screen reader works? I'm not surprised when all this leaves you frustrated and thinking that you have to do it rather than want to do it. When even a simple scan of your website gives you so many issues, of course you'll feel intimidated and demoralised. You'll never get it all done and it seems pointless to even try. Maybe this comes from how complex the web has been getting recently. Over the past 10 years, we've been adding new technologies, new workflows, new requirements and the surface area for responsibilities is larger than ever. Stop for a second and think though. What we want is to make websites that everyone can use. This is our why and that hasn't changed much. No matter how small or large your team is, no matter what framework you use and how big your stack, what comes out the other end is a product that people will use - if you let them. The classic blame game doesn't work. Accessibility is a team effort. |
Ship accessible websites. Faster.
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...
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...
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...