5 Basics to Make a Website Accessible

The topics of accessibility, screen readers, and how users interact with voice command applications can be challenging to grasp. But for 90 percent of websites, there are simple choices that will ensure the site is mostly accessible, even without a deep grasp of accessibility principles.

In this post, I’ll address just five things that make a substantial difference in the accessibility of any site. The post expands on my talk at WordCamp San Francisco in 2014.

Buttons Are Standard HTML

Buttons trigger actions. Maybe they save progress, submit a form, open a panel, or send a message. Regardless, they are buttons. So, if you’re doing any of these tasks: you should use a standard HTML button. That can either be an input element of type “submit,” an input element of type “button,” or a button element. Any other choice is not a button.

Why does this make a difference? Buttons are natively usable from the keyboard. That means that your browser and operating system already knows what to do with a button element. You can add JavaScript to make any element respond to a mouse click; JavaScript doesn’t care what element it uses. But those elements aren’t available to a keyboard. A user won’t be able to find them or activate them.

If you’ve built something that looks like a button, but is actually a span or div, then many users won’t be able to find it or use it.

Links Are Always Links

Much like buttons, links serve a specific purpose on a site: they take you somewhere. Links are also natively usable from the keyboard, so you might be tempted to use a link to perform some of your button-like actions; but you should resist that temptation. Links are one of the many elements that you can attach JavaScript to and initiate a button-like event, such as submitting a form. Links are a better choice than using a completely non-semantic element like a div or a span, but they’ll still cause some problems.

A sighted user may not be able to tell the difference between something that looks like a button and something that is actually a button; but a screen reader user will be told exactly. As a result, if a screen reader finds a link, the user may expect it to take her to a new page or a new location on the same page. If it actually performs an action immediately, that could be frustrating, and certainly makes the interface harder to use.

Remember, too, that an a element is not a link. The a element is an “anchor” element. If you add the href attribute, then it has somewhere to go, and it becomes a link. Otherwise, it’s still an anchor: a landing point that you can target with a link. But an anchor is not something that is natively usable from the keyboard — only a link.

Images Alone Are Meaningless

Images add emotional, informational, and contextual content to a website. They may convey a mood, illustrate a graph, or indicate that an item in your shopping cart is now out of stock. But those images only convey this information if you can see them. The image itself is not accessible to people with visual disabilities. To make that image accessible, provide meaningful text to share what’s in that image.

An image doesn’t mean simply a .png or .jpg file that’s inserted into your page. An image is any information that graphically represents text. It might also be an icon font character used to indicate a menu or a .svg resource. It doesn’t matter: If it’s visual, it needs text.

The way you provide alternative text will vary depending on the image. If it’s an img element directly, use the alt attribute. For icon fonts, you’ll benefit from using the aria-label attribute. It gets complicated with .svg; but you can definitely make .svg accessible.

Identifying the merits of an image requires consideration. An image that is entirely ornamental doesn’t need more context. But be sure to provide an empty alt attribute on that image, to inform screen readers that this image is intended to be ignored.

Label Everything

Do you have a form anywhere on your site? Does it have labels? If it doesn’t, then that’s definitely causing problems for somebody. It’s not hard to quickly check whether a form has labels. First, look at the form. Make sure there is text next to the form fields indicating what the fields are for. That’s a good first step. Now click on the text. Not the field itself, but the text next to it. Did your cursor automatically move into the input field? If yes, that field is labeled appropriately.

If a form doesn’t have labels, then a screen reader user has no idea what belongs in that field except by exploration — searching for nearby text that might indicate what belongs there. If there is text nearby that doesn’t explicitly label the field, the user will probably be able to find it. But she really won’t be able to tell for sure that the text she is hearing actually belongs to this field.

Have you looked at your checkout process recently? There’s nothing like having to solve a complex puzzle to enter credit card information. It leads to an abandoned shopping cart.

Manage ‘Focus’

“Focus” is an accessibility term describing where on a site keyboard commands will take effect. If you’re currently typing in a text field, then focus is in that text field. If you hit the tab key, you should be moved into the next field in the form, if there is one.

Not all people who navigate with the keyboard are blind. In fact, a significant percentage of users navigate at least partially from the keyboard all the time. People filling out forms rarely pick up their mouse to click on the next form field: they hit their tab key and move forward.

People who have more dependence on the keyboard for navigation will commonly use the tab key to get around your website. If a user can’t see where he is on your site when navigating by keyboard, your site may become nearly unusable.

Navigating by the keyboard depends on two key characteristics. First, a user should be able to get to everything on the page. That means that any dropdown menus should be reachable from the keyboard. Properly created controls and links — using legitimate buttons and links — won’t be a problem. But if you’ve used div, span, or anchor elements, there will be trouble.

Second, when a user reaches something that’s focusable, he needs to see that he’s reached it, in an obvious and not subtle manner.

Not Perfect, but Better

These five areas of basic web development will cover the needs for most users. Will you have a perfectly accessible website? No, not necessarily. This list is far from exhaustive. But you’ll have a better, more usable experience to offer everyone who visits your site.