Code Responsible

Skip navigation

You’re already doing it

Accessibility logo showing icons representing vision, mobility, hearing and cognitive“Where do I start?” … More often than not, when discussing Accessibility with a fellow developer, that’s the first question I hear. The answer I give more often than not is “You’re already doing it” and to some extent, for most developers, this is true.

See, writing accessible code doesn’t involve learning a new coding language, the HTML is the same. It really boils down to writing your code in a way that can be “accessed” by anyone, using a variety of methods. We can make our sites more accessible by simply paying better attention to our core HTML, something many of you already do.

Now, before we get too far into this I want to make one thing clear, the purpose of this article isn’t to over-simplify Accessibility or to downplay the difficulty many developers face when building an accessible site, I’m merely trying to show you how some of the coding choices you make on a daily basis increase the accessibility of your work.

Keep it simple

Probably the easiest way to create accessible code is to keep things neat and tidy. Well-formed, semantic HTML can go a long way in making you code easier to read across not only a wide range of assistive technology, but across a wide range of browsers and devices.

Consider your code order here. While CSS is great for moving elements around, a screen reader or keyboard only user don’t have the luxury of moving a mouse around to hover over a link. If an element is coded near the bottom of your html but you’ve positioned it near the top, a keyboard user might not know this and the experience can be quite frustrating. If your pages are coded in the order in which they appear, there will be less unwelcome surprises when someone is trying to tab through.

Lists

One great example is your navigation, do you always code it as a list? Years ago (and I risk dating myself here) it wasn’t uncommon for navigation (or even an entire website!) to be in a table, or just a bunch of links beside each other with no real semantic meaning. These days we don’t think twice about it, lists group our nav items together in a nice semantic “bundle” that everyone can recognize.

We even use lists for to group similar types of content together. For instance, look at the average rotating hero banner. More often than not it’s coded as a ul with some clever js and css thrown in to make it more aesthetically pleasing.

Headers

Not only headers great for titling pages and sections of pages, they are also a useful way organizing and navigating the content of a page. Screen readers can access the content of a page and read out the headers to help the visitor find the information they are interested in.

I like to compare this to when you go to a restaurant , do you read an entire menu or do you read the titles like “Burgers, Sandwiches, Pastas, etc.” to narrow down your selection before drilling down into the options. With a proper heading structure, visitors can quickly scan your pages the same way, whether they require a screen reader or not.

Alt text and images

border guard snapping on a shiny rubber glove and smiling manically into the camera

“I just need to check your… ‘documentation’ Mr. Gregory…”

Long story short – provide accurate and descriptive information for your images. Say you’ve written an amazing article on increased security at the Canadian / US Border, and you’ve found the perfect image, let’s imagine it’s of a border guard snapping on a shiny rubber glove and smiling manically into the camera, to go along with it. Most visitors will read your article and see the picture and laugh while visitors using screen readers will hear “border guard” or even worse “images/articles/border-cop-lol-large.jpg” if you’ve failed to use any alt text at all. If a picture can paint a thousand words, try using more than two to describe them.

CSS Focus

It doesn’t get any easier than this. For every :hover pseudo class you have, use a :focus. See, “:hover” works exactly how you’d think, when the mouse hovers over it, the pseudo class kicks and and the styles are applied. So what happens when someone isn’t using a mouse? What if they’re using a keyboard? Those don’t hover. If you’ve added the :focus pseudo class to your css, no problem! The styles used for hover are also applied when keyboard focus is received.

This one is actually a bigger deal than you’d think. Without proper focus, a visitor using a keyboard might not be able to figure out where they are on your page. Here’s an easy way to test your focus. When you load your page, don’t look at it, just hit tab a random number of times. Now look at your page, can you tell within a few seconds where the focus is? If you can’t, how do you expect others to?

In Closing

Now, we’ve just begun to scratch the surface here, but hopefully this will instill a little bit of confidence in you to start implementing these tips into your work. These won’t make you code 100% accessible, but it will go a long way to improve the overall accessibility of your site.

Billy Gregory

Aside from being a pretty good guy, Billy Gregory is a Front-end Developer, as well as an active member of the Toronto Accessibility community as an advocate, speaker, and a practitioner.

5 Responses to “You’re already doing it”

Leave a Reply

Comment Form