What developers need to know about accessibility

Here we’ll look at the common issues and best practices that developers will have to get to grips with when it comes to accessibility compliance. 

If you end up having to do an accessibility audit, try not to worry! Coding for accessibility leverages what you already know about writing code, but also introduces best practices and small modifications to enhance the experience for users with assistive technology.

If you’re an advocate for self-explanatory, neat, clean code then you might not have too many changes.

The easiest way to start accessibility testing is to get into the right mindset by understanding why you’re doing it. Though there are a variety of impairments to address with accessibility, vision impairments are the trickiest, which is why you’ll see so much information on how to code for screen readers specifically.

Five common accessibility issues and best practices

Since accessibility ties into multiple departments, you probably need to liaise with your design, user experience and content teams. But since you are likely the final step of input before sending your product along to users, it’s a good idea to come armed with good practices in mind.

Some of the most common issues you’ll run into are:

1) Appropriate alt tags

Use appropriate tags to label images that are worth describing, and leave them blank for decorative images. For example:

• It’s normal to label your logo with a vague description: <img src=”/images/logo.svg” alt=”XYZ Company Logo”>
• If you use a fancy picture for your bullet points or horizontal rows, leave the alt tag blank: <img src=”/images/horiz-row.jpg” alt=””>
• For meaningful images, give them a useful description: <img src=”images/food/pizza.png” alt=”A pepperoni pizza cut into 8 sections”>

2) Use appropriate color contrast ratios so it’s easy to tell the difference between foreground and background

If your design team needs some convincing, point them to materials about meeting AA standards for color contrast so you can work together to make your whole page friendly for colorblind and low vision users. This only affects the color palette you’re using, so if you use CSS variables and preprocessors, then this is going to be a piece of cake.

3) Use good coding practices, proper tags and descriptive labels

For example, use divs and classes appropriately, and give them useful labels like <div class=”office-contact-info”> instead of <div class=”info”>. Use page elements that functionally make sense with the design, even if visually they appear different.

For example, use a list with radio buttons if you’re asking a user to select one option, even if they visually look like buttons. Screen readers use different shortcuts to interact with different elements, which can affect the behavior.

4) Be as descriptive as possible

Screen readers can navigate websites by listing out headers, links, edit fields, etc., so be descriptive – especially with links.

If your screen reader lists out all the page links that only say “click here” “click here” “click here” that isn’t particularly helpful. Instead, use more detailed link text, like “download the transfer form,” “read about our staff,” or “see all our routes.”

5) Error messages that actually help people

Use helpful error messages that tell the user where to find the problem, how to fix it, and most importantly give them a way to recover from it.

Maybe you validate form entries in real time, or have a step to confirm your information before submitting. This could prevent someone from having to fill in the whole form a second time just because they used the wrong date format.

It’s easiest to learn how to code with accessibility in mind so that you can ensure an accessible site going forward. Once your template is in a good spot, you won’t need to go back and fix these issues over and over again.

If you need help prioritizing what to tackle first, it’s easiest to start with an automated scan using tools like AChecker, which lets you scan a URL or paste code, or WAVE, a web accessibility Firefox add on and Chrome extension. These tools will give you an idea of where to start.

Lets look at some examples of each, using a W3C demo page as a practical example.

Accessibility scanning tool example: AChecker

Some checkpoints are self explanatory. This example refers to the WCAG Guideline 1.4.4, titled “Resize text.” The sub-issue within the “Resize text” category asks that you use <em> or <strong> instead of <b>. This is marked as a “Known Problem,” which means that the tool can scan the code automatically to identify where this issue occurs.

Other checkpoints can have a scan that automatically identifies instances where this may be a problem, but it still takes a human to verify if this is an issue or not.

In this example, it’s pointing out that these images have alt text, but might not need alt text if they are decorative. The first three images are logos with appropriate alt text, such as alt=“W3C logo” or alt=”Red dot with a white letter ‘C’ that symbol … which is sufficient. The last one, however, is actually a decorative image used as a bullet point. It uses alt=”bullet” which you don’t actually need, and instead should use alt=””

Other examples may be more vague and may require you to use your discretion to see if it’s an issue or not. In situations like this, it’s helpful to know what your code is doing so that you know how to test it out.

In this example, you’d need to make sure that you can get to and interact with all elements on the page by just using your keyboard, instead of a mouse.

But lots of these situations won’t apply to anything on the page at all. That’s why it’s really important to have an actual human verify these issues instead of just relying on automated scans.

Accessibility scanning tool example: WAVE

The Wave Chrome extension and Firefox add-on gives you a more organized, visual way to assess the accessibility, but you pretty much have to review one page at a time.

However, if you have the time to go through the tool, it points you towards lots of helpful resources describing what each issue is, where it is on the page, what line of code it refers to, how to fix it, and more.

Having the visual sidebar can help you wrap around what the issues are, and it points out each specific instance on the page. It even has its own built-in color contrast analyzer.

If you do want to go beyond standard accessibility practices, or are having a hard time making your code accessible, you can use Assistive Rich Internet Applications (ARIA) to help screen readers interpret how to parse your code. Of course native HTML is best and more globally accepted by assistive technology, but ARIA lets you define additional attributes that help assistive technology know what to do. For a quick overview, you can read the intro from Mozilla, Google, or straight from the W3C. You can even watch a free course by Google through Udacity on how to use ARIA and other accessibility techniques.

There are countless tools out there that make accessibility testing much more manageable. With such a large variety, you’re bound to find a tool that suits your preferences, or maybe you’re even lucky enough to find one that integrates with your bug tracking software. No matter what tools you go with, be realistic about how quickly you address each checkpoint and you will be accessible in no time!