The websites I work on at my job score relatively poorly when it comes to accessibility. When I say “relatively poorly”, that means interactive features are not keyboard navigable, many sites contain an outline: none, lack appropriate section headings, and contain prevalent “Click here” links. Images may or may not have alt tags, but everything does have some baseline accessibility due the nature of SEO-friendly markup. “Relatively poorly” is a pretty generous assessment, to be honest.
In fact, thinking about accessibility on our sites evokes an image of a menacing, impenetrable storm cloud of guilt hanging over my head that just gets closer and closer to suffocating me.
But wait, it doesn’t have to be like that!
I want to encourage anyone else who, like me, understands the importance of accessibility but feels totally helpless working on large, inaccessible websites to adopt this mindset: accessibility – in said, big, legacy code-bases – does not have to be all or nothing. A little bit at a time does a lot over time. At least that’s my philosophy moving forward.
For this particular project, I needed to re-purpose a video-carousel-thing to work on a different part of a site. The original video-carousel-thing was not navigable by keyboard and made no sense in a screen reader. As I went through the motions, trying to change the minimum amount of code to accomplish the task, the aforementioned storm cloud came so close to cutting off my airflow I said…FUCK IT, THIS WILL BE ACCESSIBLE IF IT’S THE LAST THING I DO.
And hey, guess what? Now the video-carousel-thing can be navigated with a keyboard and makes sense when read with a screen reader.
It probably added 2-3 hours to a 25+ hour undertaking – definitely not enough to make a consequential difference in the delivery of the feature (my inability to resist refactoring CSS did that…). Here are some things I did to make the video-carousel-thing accessible:
- Refactored the templates to the
buttonelement for the large video thumbnails - Refactored some JS event handling to be more state-driven and added the event listeners to the buttons
- Adding some visually hidden text to indicate that the buttons would play a video
- Added a visually hidden heading to a
sectionthat otherwise only displayed a logo - Tested the screen reading and keyboard navigation using ChromeVox
As an added bonus, the other developers on my team – who are are newer to a11y practices – can now learn by reviewing my code, no extra study necessary! Code reviews are a powerful educational tool.
So, now that I have this much more reasonable view of what it takes to work on accessibility, the menacing storm cloud has dissipated! Thinking about accessibility on our sites now offers waves of sunny energy and satisfaction instead of suffocating guilt. Any code I touch in the future, gosh-darnit, will be accessible and you know what? It probably won’t even take that long.