Good Coding Habits for Accessibility

October 25, 2014

Topics: Accessibility, WordPress.

This is the written version of my talk at WordCamp San Francisco 2014. Watch the video at WordPress.tv.

Do you think web accessibility is hard?

You’re right. Web Accessibility is hard in the same way that everything else in development is hard: designing and building any perfect product is always tough – even impossible. But getting 90% of the way there is easy.

But I’m an advocate for practicality. So don’t set perfection as your goal. Just make things better.

How to make Accessibility Easy

Start with the basics: writing code right. The core of accessibility is well-written, semantic HTML.

  1. Buttons are buttons.

    A button triggers an action – saves a post, opens a panel, sends a message — whatever. If you’re activating a behavior, use a button. Yeah, you can build something custom. Then you need to add tabindex to make it focusable, write controls to trigger the action on keypress, add ARIA attributes to indicate the button’s current state — or just use a native button, where all of this comes for free.

  2. Links are links.

    Links point to resources — that might be a link on the same page or on another page; but if you’re sending somebody somewhere else, you should be using a link. And an anchor without an href attribute isn’t a link.

  3. Images are meaningless.

    When I say image, what I mean is any graphic — not necessarily an <img> element; it could be a font icon, or it could be punctuation. An image is worth a thousand words — but only if those words are available to the visitor. By itself, it’s not machine readable. You can only get meaning from an image if you can see it. So any time you’re adding an image – anywhere – consider what it means to the user. Is it purely ornamental? Cool. Then ignore it; no need to back that sucker up. But if it’s more than that – if it’s a hamburger icon that opens a menu, an arrow that sends you to the next page, or a balloon that sends you to comment on a post, then you need some text to back it up.

  4. Label all the things.

    Forms without labels may injure small children. Are you taking input with that form? What is it? If I can’t see the form, can I tell? Placeholders aren’t labels — they may not be read out by assistive tech, and as soon as you enter text, they’re gone. Labels should be visible unless the purpose of the form is totally clear; and must be explicitly associated with one input field.

  5. Focus, focus, who’s got the focus?

    People who navigate by keyboard aren’t always blind – so they don’t get audio cues to tell them where they are on the page like a screen reader might. If you don’t have a visible focus state on an element, that’s a great way to lose your visitors. Make sure your users have a “you are here” experience, wherever they are on the page.

    Pay attention to focus assignment – oOpening a modal? Make sure to move focus to the modal. Closing one? Make sure to move focus out.

How to make accessibility hard.

Blame it on the technology

Yeah, there are all sorts of limitations in assistive technology. Yes, there are bugs. Yes, there are specifications that aren’t well supported. But your primary mission is to write good code. Sure, you can expend a ton of labor in handling assistive technology bugs and limitations. But that’s where the 90% stops: 90% of accessibility is writing good code. Going the extra mile is totally worthwhile – but we can’t pretend it’s easy.

Leave it for later

Every decision you make through the course of your project has consequences. If you decide to start without accessibility, then add it later, you’re asking for trouble. Some fixes can be invisibly and easily added; but others mean tearing down your existing HTML and CSS and replacing them with something new — when you could have just done it right the first time.

/* This is wrong; but I'll fix it later. */

You should never write this, or any variation of it. Don’t write code you know you need to fix later.

When you’re adding an icon, you should be adding the text that goes with it. When you add a form, add the labels. When you wireframe your theme design, add ARIA landmark roles to describe the purpose of each large section of the page. The minute you place the cursor on the screen, you should be thinking about the accessibility of your product. Accessibility is part of the basic functionality of a good product.

Have something to contribute?




« Read my Comment Policy

3 Comments to “Good Coding Habits for Accessibility”

  1. Thanks for your comments, and for sharing the post!

  2. Another excellent blog, thanks Joe!
    Also, for more on links and buttons, see my blog Proper Use of Buttons and Links.

  3. Nice summary of the easy parts which—sadly—are either forgotten, or ignored by a lot of developers.