Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to encourage accessibility in an organisation? #88
Note: this question has been asked by Andy Lincoln on Twitter who kindly accepted I repost it here.
At my current job we currently do not scope our projects or allocate resources to making sure our sites are accessible. I do my best to make things as accessible with the knowledge I have, but I know I have only just scratched the surface with tackling accessibility. I don’t get the chance to put that polish into the products because the mindset of the other devs is that accessibility isn’t a huge priority, or its something extra we have to sell customers on. Some of our devs have even voiced how much they hate coding for accessibility.
This particularly concerns me on some projects that have wide impact like school websites. I’m currently working on a WordPress site for a high school and it was not until I brought up accessibility during the design handoff meeting was accessibility brought up as a concern when I saw placeholder inputs on forms with light grey text.
My company also does a lot of hospital websites as well, so between those to types of clients I feel like it's irresponsible at the least and downright unethical at the worst to make websites without these considerations.
Any advice on encouraging accessibility in a constructive way? I'm afraid of coming off in a bullish manner about this, but it is really important to me.
Any input would be much appreciated!
The usual “my company doesn’t give a shit about accessibility, how do I change that?” That’s a tough one, and unfortunately at the end of the day, there is only so much you can do to help.
But let’s not lose all hope just yet! There is actually quite a few ways to tackle this problem. Accessibility is not just about coding. Everyone is involved. Designers, developers, QA testers, product owners… Everyone can do a little bit. And if everyone does a little bit, it’s not that hard. But it cannot be owned by someone. This is why we need champions. And in your company apparently, you’re the accessibility champion!
The problem with accessibility is that people consider it the cherry on top of the cake, then because no one wants to pay for the cherry, no one takes care of it. But would you imagine if we did the same for design? “Nah, let’s just build it, design is not a priority, we’ll do it at the end if we have time.”
The first thing I believe is worth noting is that accessibility is not about doing more work, it is about doing the correct work from the start. Taking a fundamentally inaccessible website and turning it into a fully accessible and inclusive experience is definitely going to cost time and money. But when it comes to new project, producing accessible content is surprisingly easy and definitely results in a much better product. Which means more money. Which means happy investors, managers or whoever.
Now, what can you do to champion this idea? Unfortunately, it is a battle you’ll have to tackle on several fronts. One is with the developers. Most front-end developers do not build with accessibility in mind because they never learnt to and have no idea where to start. I don’t believe anyone is failing that much at being human to the point of saying “screw the disabled, I’m not doing it.” If you work with people like this, I highly suggest you change job.
More often than not, it’s not malice, it’s just ignorance. The good thing with ignorance is that it is easy to fix. What you could suggest is to organise a little workshop on accessibility. Start with something small: a one hour session on what exactly is web accessibility, why you think it’s important, what are the benefits and why it’s not that hard. Then if people enjoy that, do another session a bit more hands-on. Don’t go too deep into ARIA shenanigans and things like this. This is where lazy devs tend to go “meh, not worth it.” Stay high-level for a little while. You can’t teach anyone to code for accessibility if you haven’t at least convinced them that it’s worth keeping in mind.
Then, there will be designers. Considering accessibility starts way before the implementation phase. There are so many ways to screw up accessibility without even hitting the browser. Whenever working closely with designers, it might be a good time to start dropping hints about accessibility, without necessarily phrasing it this way. Mentioning color contrast, ease of navigation, context switching, ways of browsing the web, and so on… I’ve been surprised at how much designers are willing to do the extra step and design an inclusive experience when they realise what the challenges are. It’s very exciting.
Once accessibility becomes a bit less of a burden thanks to this constant work with designers and developers, you’ll be able to bring that more easily to product owners and managers (or whoever makes decisions in your company).
This is what we did at N26 for instance. When my friend and I joined a year ago, accessibility was absolutely not a topic. And for us, it was absolutely not negociable. We told no one, we just did it. We built everything as accessible as we could. Eventually, we started mentioning that our platform was accessible for screen readers, visually impaired, and generally people suffering from a handicap. Then people realised that a) it can be done silently during development; b) it’s not as hard as they thought it would be. From there, we were able to make accessibility a non-functional requirement, that is, something that has to be done to be considered shippable. But would we have brought that a year ago before starting the new platform, nobody would have been onboard.
I’m not going to shit you: it’s going take time and efforts to make people realise it is the right thing to do. Even bringing the ethical discussion on the table is usually not enough. But if you believe in it (and I think you should) and if you enjoy that, it’s going to be worth it.