Coding accessibly might seem intimidating at first, but once you dip your toes in the water, you’ll quickly see that it’s not so scary after all.
Join the DZone community and get the full member experience. 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. It can be easy to build up the idea of coding accessibly in our heads into something so large and intimidating that we can always find an excuse for putting it off. But in reality, accessible code is a series of small to moderate adjustments to your development and testing process that are all completely doable by developers of all experience levels. After all, as developers, learning new stuff is just part of our job. When your team decided to switch from JavaScript to TypeScript or start using React Hooks, you probably picked it up after a bit without too much pain. Frameworks, libraries, best practices, even languages themselves change and evolve over time. Once you start thinking of accessibility the same way and recognize that it’s not an optional upgrade, you can start to build accessible development into your existing processes and patterns at work. The best way to start is to start small and work up. If you’re working in a naturally component-based application (like an Angular or React app), this approach works especially well because you naturally have your application broken down into those building blocks. You can start adding accessibility features to your base components, then get it for “free” as you scale and use those components in other components (and then those components in other components, etc.). It also helps the task feel less intimidating. The whole application doesn’t have to be perfectly accessible today; today we’re making an accessible button. But then that button will get used everywhere in your app, and just like that, you’ve made a huge accessibility upgrade! Pick out a handful of your base elements that get used over and over throughout your application. Then, you can run a quick accessibility check on each one by looking at your code and asking the following: The single most powerful way you can improve accessibility in your application is to make sure you’re always using the correct semantic element for the job. Semantic HTML helps tell screen readers what they’re looking at, makes keyboard navigation easy, and intrinsically organizes your page. When we open a website or app, we usually do a quick visual skim over the contents to quickly find what we need. Your visually impaired users can’t always do that, but their screen readers can. Screen readers can read out headings for sections and allow users to skip ahead, inform users what they can interact with by looking for buttons, read out content in list format, quickly navigate menus, forms, and more; but only when you’ve used the right elements, and not just thrown a div on everything. Image from https://www.w3schools.com/html/html5_semantic_elements.asp You’re probably already familiar with a handful of common semantic HTML tags: the text-related tags (h1 through h6 and p) are probably the most well-known, although button or img might give them a run for their money. In addition to those, your application will benefit from using nav for your navigation, header and footer (which do exactly what they say on the tin), main, section, article, and aside to define your content, forms for user-input forms, and table for data tables. Thankfully, the days of tables for layout are long behind us (as long as you’re not coding an email). There are some less-common ones as well, such as progress for progress bars, or cite for the title of a work. It’s worth getting acquainted with the current list of available HTML5 elements if you aren’t already. The more you can use correct semantic tags, the more accessible your application will become. If that wasn’t enough reason, you’ll also find that a semantically written document is a lot easier for your developers to quickly parse and work with as well because they can see at a glance what each element does and why it’s there, so it will speed up your dev time and ease your onboarding, too! Semantic HTML updates are easy to make, just swapping one element for another, and they don’t usually create many (if any) breaking changes.
