Why Does Accessible Development Feel So Intimidating?
I’ve found accessible development to be one of the places where it’s easiest to fall into analysis paralysis: there’s always something that you feel like you need to double-check first, something that you heard someone else is doing, or just a vague feeling that you don’t really know enough yet to start tackling accessible coding yourself. Just one more blog, one more conference talk, one more video, and then you’ll be ready to start writing accessible code.
Meanwhile, our applications – and more importantly, our users – are stuck with the same old inaccessible code that we just keep writing. The best thing we can do is to start writing accessible code to the best of our ability, with the acknowledgment that we might make a mistake! After all, isn’t that just how development works all the time? We code things using the skillset we have, adhering to the best practices that we’re aware of and the current web standards. Sometimes we make mistakes, whether those are bugs or architecture approaches we would have done differently in hindsight, but we still ship an application that’s (hopefully) mostly functional. Accessibility is the same way: it functions on a sliding scale, not an on/off switch. We code accessible features as we’re able, based on what we know right now and the current accessibility-related guidance. It might not be perfect 100% of the time, but anything is better than ignoring accessibility entirely. And hey, code isn’t carved into stone, right? You can always go back and update something once you’ve learned how to do it better.