Info about this article: I won't publish a second part of this article, as there are a lot of good resources already out there: WebAIM, The Accessibility Project to name a few.


For my last project at TWY GmbH I needed to ensure the conformance Level AA of the W3C Web Content Accessibility Guidelines 2.0 on a few landing-pages and a huge amount of email-templates.

Accessibility is a big word and has already been discussed a lot on the interwebs... But the state of tools is lacking and what is clearly missing, is a nice little guide to get you started with the key-points.
That's what I want to accomplish with this series of blog-posts.

Let's get started

I recommend to read this article to get on track with web accessibility and afterwards setup your environment for testing and fixing accessibility-issues.

I assume you have already setup a development-environment with your favorite IDE, command line and browser(s) - so we can dive right into the tools for accessibility-specific testing.

Screenreader

I strongly recommend you to install a screenreader to test all of your webpages (or modules/parts of it). If you're on a Mac like me, you could simply grab some earphones and start with VoiceOver. You can find a good guide here: Using VoiceOver to Evaluate Web Accessibility.
If you're on Windows (or have a Virtual-Machine ready) I suggest you to use NVDA.

I used both of them (NVDA on a Virtual-Machine) and focused on the results I got from NVDA, as our external testing company relied on it.

INFO: Do not use browser screenreaders (like Fire Vox) as it does not reflect the real state of a user with a screenreader (they need a tool for the hole operating system, not just the browser).

Browser extensions

For quick testing the source-code (simple issues) I used the Accessibility Developer Tools and the WAVE Toolbar in Chrome.

For the document outline (WAVEs feature did not work with a file-path) and disabling styles (I like one-click-tools ;)) I used the Web Developer extension.

Command line tools

If you like to work with a command line tool, I would recommend a11y from Addy Osmani. As it seems to be the only one, who really works. Unfortunately it crashes if you test a lot of files (about 100, I'm not really sure at what amount exactly) which made it unusable for me.
I tested a lot of other tools (also in conclusion with gulp and grunt) but didn't found one which met my needs...

Basic Html issues

Let's start with the basics in your Html - we will dive deeper into aria-roles and attributes in a later blog-post.

Language

Be sure to set the lang-attribute on your Html-Tag:
<html lang="de"> or <html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de"> if you're using XHTML-Standards. You should add this regardless of your desired accessibility requirements as it's just nice for users and bots. More about it here.

Images

Every image should have an alt-text set. If it's just for decoration add an empty alt-text and the screenreader will ignore it. If an image needs to inform the user about something, add a informative alt-text. Do not describe the image itself, but why it's placed here and relevant for the content.

The purpose of each link should be clear from the link text. So try to prevent empty a-tags or add a visually-hidden text in it for screen-readers only (I like the implementation of bootstrap).

If a screen-reader sees an empty link it either just says "empty" or repeats the hole URL.
Especially in our shiny single-page-app world with our "hashtag-links" and "navigation-dots" add an informative text for what this link is used for.

Input labels

Ensure that every form element (text field, checkbox, dropdown, etc.) has a label and make sure the label is associated to the correct form element. Do not rely on placeholders, as these are not meant to be a label-replacement. Bootstrap does a really good job in its documentation:

<label class="sr-only" for="exampleInput">  
  Email adress
</label>  
<input type="email" class="form-control" id="exampleInput" placeholder="john.doe@example.com">

Tabs, scroll-navigations, accordions, etc.

Make clear which element is active, by simply adding a screenreader-only text to it, like:

<a href="#more-about-m43nu" class="active">  
  <span class="sr-only">Active menu item:</span>
  More about M43nu
</a>  

Document outline

Be sure to use a hierarchical correct and informative heading-structure. It's a good idea to structure page-components with screenreader-only headings like header and footer to inform the user about where he currently is.

Document Outline in the Web Developer Toolbar

Test the document outline with an extension for missing levels and read through it carefully. Does it seem to be correct? Is it really informative?
I've seen a lot of misleading level-structures or missing levels of headings as the design was not laid out for another heading here and there. Use common sense here and think about it when reading it through.

Contrast

There may be elements on your page where the contrast does not meet the minimum requirements for the windows high contrast mode. There are several tools to test for this (there is a tab in WAVE for it) and a bunch of contrast-calculuators (I used and recommend this) but if you want to see it for yourself, activate the high contrast mode on windows.

If you cannot change your design to match the contrast, there are media-queries to target it:

@media screen and (-ms-high-contrast: active) {
  /* All high contrast styling rules */
}
@media screen and (-ms-high-contrast: black-on-white) {
  div { background-image: url('image-bw.png'); }
}
@media screen and (-ms-high-contrast: white-on-black) {
  div { background-image: url('image-wb.png'); }
}

If you have a really large page with a hole lot of navigation-entries or other stuff before the main-navigation or content, it's nice for a screenreader-user if there are skip-links to jump to the main-navigation or to the content.

Skip navigation link

This adjustments are not necessary for Conformance Level AA, but as we are always concerned about the usability of our websites, why not cover the complete user-base?

Follow-up

That's it for the basics.
I will cover roles, aria-attributes and making javascript-widgets accessible in my next blog-post. Stay tuned!