The Accessibility Battle
Accessibility is an essential and very crucial aspect in web and mobile development. Allowing for access for ALL users to be able to use the content you create in the digital space.
So why does it feel like that isn't the case? Like there is something always in the way from making those big gains. Constantly being told "No", "We'll fix it later" or "We know it's important but it is not MVP".
Working in the accessibility space and trying to advocate for accessibility on your development team can feel like you are never making progress. It takes a very persistent and tough mindset to push through all of it and keep advocating, but even with that you may feel defeated. DON'T!
Naturally we as humans want to put a plan together, snap our fingers and hopes it all goes perfect. Accessibility is no different, but change is always difficult for agile development teams. One thing I have learned over my time in the accessibility space is to TAKE THE SMALL WINS!
Small Wins, Big Gains
Let's take a development team that is agile and is a well oiled machine. They are pushing new content every two weeks and have an air tight process from beginning to end. In the past what I would do is go to these teams and say "This is accessibility, and now we are going to do training, automation, manual testing and it will now be a part of your process".
Immediately, the development teams already have in their mind "Wow, this is a lot" or "I thought accessibility was suppose to be easy, this isn't". Like with anything, we can't just flip a switch and accessibility is happening on a development team. We need to build with small wins that will pay off with big gains.
Instead of pushing everything all at once, start with what is most simple for the development team. Finding out where accessibility can fit immediately in a development team helps ease the pain of adding a new thing to their process, but also shows how simple it really is.
A sample set of steps I have taken in my past looks like this:
- Accessibility Linting
- Accessibility Training (On their own)
- Automated Accessibility Testing at Unit/Integration Level
- Manual Testing without Screen Reader
- Screen Reader Training/Workshops
- Full Manual Testing of New Content
- Accessibility as Definition of Done
Those steps laid out above could take however long they need. Maybe it's a few weeks or couple of sprints per each. This is the way that I have had the most success is making accessibility simple and easy for teams to adopt.
Seeing Progress
In the perfect world every accessibility professional or advocate would love for everyone to drop everything and say "we are now making accessibility part of the process full stop". Absolutely! Unfortunately, this is just not the case in practice.
Meryl Evans says it best, "Go for progress, over perfection". Yes you will be told "No" and you will be met with frustrations, but just know if you take the small wins, they will add up. Maybe not today, or the next week or month, but over time you can build accessibility in the development teams or organization you are in if you take the small wins.
Lastly, I want to leave with this for my accessibility advocates. Be kind to yourself. We all may feel defeated and beat down, but keep fighting. Make sure to take a step back and look at the progress you have made to help build accessibility up and keep fighting the good A11y fight!
Top comments (0)