If you’re like me, you’re one of the web developers on your team tasked with taking something seemingly-boring – like a mortgage calculator – and making it:

Look and work fantastically. Something like Google Docs meets Facebook meets Spotify meets Snapchat… SnapDocBookify? Yeah, make that. Meet the demands of the client or business partners, even if they think your mortgage calculator needs a weather widget with room for the 7 day forecast on an Apple Watch. Fully accessible and WCAG AA compliant. Wait, what

Yep. Right now, maybe not surprisingly, #3 might seem the most daunting. Thankfully, it doesn’t have to be that bad. Let’s take a look at some of the free tools available that make our lives (and the lives of people with a disability) a bit easier!

Accessibility Developer Tools (by Google)

Google’s offering is a Chrome extension that adds an audit pane to the DevTools. Within, you can run an audit on a page and the tool will return information and warnings on elements that potentially violate accessibility guidelines.

Google’s Accessibility Tools in Chrome

It’s great for a quick overview of any outstanding defects. You can edit the element inline in this panel (changes are reflected in the Elements pane) so it’s nice for quick checks and tests. Clicking the link provided for more information will take you to Google’s Github repo with code examples showing best practices, along with links to referenced specs. I also like the way violations are grouped by the level of severity. Awesome.

Download Accessibility Developer Tools here.

aXe

aXe is another Chrome extension that adds an additional panel to the DevTools. Within this panel, you can analyze a site for accessibility violations and warnings. aXe will let you know how serious the violation is, what WCAG guideline is being violated, and details about the element in question. It’s main benefit over Google’s offering is that it’s a little more detailed about feedback, and includes a summary on how to potentially fix issues.

One of my favourite features of aXe is that you can click on the “Inspect” button and it will take you right to that element in the Elements panel. You can test your fixes there, and re-analyze the page to see if there’s improvement. I’m more used to making the changes directly in the Elements panel, so I like that.

You can download aXe here.

Color Contrast Analyzer

Yes, ’tis another Chrome extension, lads. This one will add a mask to your page with a visual map of contrast. Here it is below on Google’s homepage:

Left: Plain Google. Right: Google with the Color Contrast Analyzer’s mask overtop.

The mask overlays your page and adds a white border between colours that have sufficient contrast. As you can see, in areas where contrast is low the border dissipates and creates gaps; these areas are worth a second look. This mask works across the whole page, over text, over images; everything.

It’s worth noting that not everything on the page is subject to a minimum contrast requirement as set forth in WCAG. Logos, disabled buttons, and some other items are exempt. In Google’s case, their site meets contrast requirements. (Good job, Google.)

Download Color Contrast Analyzer here.

WAVE Evaluation Tool

WAVE has been around for a while. Much like aXe and Google’s Accessibility Developer Tool, WAVE will audit your page for accessibility warnings. Unlike those tools, though, it will show you the results inline on your page:

WAVE in action

This is great because it gives you a visual indication up front.

Some great things WAVE has going for it:

You can click the left panel’s tabs to view the different successes and failures on the page.

You can click the icons next to the test results to be taken to the icon on the page.

You can toggle the view of individual warnings on/off from the panel’s checkboxes. (For example, you can choose to only show errors.)

You can click an icon on the page to reveal a pop-up with more information about the test, and why it passed or failed.

There’s a code panel you can expand from the bottom of the screen to see the warnings inline with the code they’re tied to.

You can toggle styles off and view the tests inline that way.

You can also check colour contrast. However, WAVE does not account for background images, gradients, etc.

The main downsides to this tool is that there are some things on it that don’t always work. Some of the tests return false positives, and sometimes clicking the icons doesn’t work as you’d expect.

Download WAVE here.

NoCoffee

This Chrome extension is a lot of fun. NoCoffee is a vision simulator that can help you understand how people with vision impairments view your pages. It’s rife with customization options and presets ranging from simulating different colour blindnesses, to retinal detachment, to visual obstructions like floaters (and they move).

An example of Google’s homepage with NoCoffee running. Trippy.

Before I used NoCoffee, I had no idea there were so many unique forms of visual impairment. Using this tool will help you understand what many have to go through to interact with the web on a daily basis.

One potential drawback to this tool is that it seems to affect every open tab in Chrome, which may not be what you want (if you do side-by-side tabs on a wider monitor, for example). Just make sure you reset the tool once you’re done using it.

Download NoCoffee here.

The Accessibility Inspector + the Accessibility Tree

Beneath your browser’s pretty exterior is the accessibility tree. The accessibility tree is very similar to the DOM tree; it is a hierarchical structure of accessible objects.

An example of the accessibility tree, on an <a> tag

An accessible object (the nodes you see above) is created in the tree for every element on the page, if that element should be exposed to assistive technology. In some cases, if the element isn’t deemed useful, it’s not exposed. This data is shared with assistive technology to determine what it is that’s being looked at or focused on, what to announce to screen readers, and other instructions.

Viewing the accessibility tree on OS X

There are a few ways you can view the accessibility tree on OS X. The best way to do this is to first get Xcode. Once installed, open it and head to Xcode > Open Developer Tool > Accessibility Inspector. This will open a window that sits on top of everything else, where you can view the accessibility tree. The tree is within the hierarchy panel.

When you hover over something on your screen, you’ll see the Accessibility Inspector’s panels change and update with the information on what’s under your cursor. If you want to lock focus on an element, you can press ⌘-F7 to lock the Inspector on that element. From there, you’re free to mull about the Inspector’s pane without worrying about the mouse changing focus.

Just beneath the hierarchy panel, you’ll see the attributes panel. Here, you can view all of the data associated with your active element. The data includes how the element has been interpreted; listing its labels, text, and other goodies.

The Accessibility Inspector also works system-wide in all applications (to varying degrees), not just our browser. Sweet!

Viewing the accessibility tree in Windows

Here’s a similar tree-viewing tool for Windows (called Inspect) that comes bundled with the Windows Software Development kit in Windows 8.1.

Viewing the accessibility tree in Chrome

Chrome also has its own built in accessibility tree which you can inspect on a per-tab basis. You can get to it by going to chrome://accessibility. Here, you’ll see all of your open tabs and extensions and you can toggle the accessibility tree view for them on and off.

Chrome’s built-in accessibility inspector.

As you can see, it’s a lot harder to parse in Chrome. But it’s still good for a quick overview to see what’s available, and it’s fully searchable with ⌘-F (or ctrl-F). The Chrome team has also documented accessibility in Chrome.

(OS X + iOS) VoiceOver

VoiceOver is a screen reading tool used to operate and navigate the system and applications on Apple’s OS X and iOS. It has a learning curve, but once you’ve gotten used to it, it’s an indispensable tool for testing accessibility.

To turn on VoiceOver on OS X, go to Apple > System Preferences > Accessibility > VoiceOver > check “Enable VoiceOver”. You can also press ⌘-F5 to toggle, which is much quicker.

To turn on VoiceOver on iOS, go to Settings > General > Accessibility > VoiceOver > toggle VoiceOver. You can configure a shortcut in Settings > General > Accessibility > Accessibility Shortcut.

Navigating VoiceOver on OS X and iOS is a bit tricky. There is a practice option on both OS’s that I recommend trying out to get the hang of things. The first time I tried VoiceOver on iOS, I had a hard time turning it off!

Use VoiceOver to navigate and listen to your web pages. Depending on the browser used, you’ll get varying results. Safari has the best support for VoiceOver on iOS and OS X, and based on information gathered from the industry, this is the browser most people with disabilities will be using. Often, I will build a test a web tool extensively in Chrome and then move to Safari for screen reader testing.

VoiceOver OS X basics

Control and option (held together) are known as the VoiceOver (or VO) keys. They’re the primary means of accessing VoiceOver’s controls and commands.

To access help, press VO + H . You can use the arrow keys and enter to navigate the menu.

. You can use the arrow keys and enter to navigate the menu. Navigate the DOM by using VO + arrow keys .

. In a web browser, VO + U will open the web rotor. From here, you can navigate web pages via headings, links, landmarks, and other areas of interest. The arrow keys left/right move between these different options. This is a common way of navigating pages.

VoiceOver iOS basics

Swipe with one finger left/right to move between items on the screen one-by-one.

Double-tap with one finger anywhere on the screen to activate the item that is currently selected.

Use three fingers to scroll.

Use a two finger twist gesture to access the web rotor in a browser.

You can read Apple’s guide to VoiceOver on OS X here. To find information on VoiceOver on iOS, you’ll have to head to the manual on your specific device. You can get the manual here.

(Windows) JAWS + NVDA

Of course, VoiceOver isn’t the only screen reader out there... It also isn’t the most popular. NVDA (free) and JAWS ($) are two more popular options, however they’re only available on Windows machines. It’s still possible to test on OS X, however:

TL; DR

That’s all, here’s a quick summary.

Chrome extensions

OS X + iOS tools

Xcode

Open the Accessibility Inspector (Xcode required): Xcode > Open Developer Tool > Accessibility Inspector

Turn on VoiceOver OSX : Apple > System Preferences > Accessibility > VoiceOver > check “Enable VoiceOver” (or ⌘-F5)

: Apple > System Preferences > Accessibility > VoiceOver > check “Enable VoiceOver” (or ⌘-F5) Turn on VoiceOver iOS: Settings > General > Accessibility > VoiceOver > toggle VoiceOver

Other tools

(Here’s a similar tree-viewing tool for Windows that comes bundled with the Windows Software Development kit in Windows 8.1)

A few people have reached out and suggested a few more tools:

Tota11y — An open-source JS tool that can run as a bookmarklet or from source. Highlights common accessibility errors, similar to WAVE but the interface has more polish. (via MisterZia on Twitter)

Accessible-colors.com — An in browser colour contrast checker. This is nice because it recommends WCAG AA compliant alternatives to your colours in real time. (h/t to Misha Moroshko)

One last thing…

If you’re doing development with local files, you’ll need to switch on this Chrome setting to give the extensions above access. You’ll find this under Chrome menu > More Tools > Extensions:

Make sure “Allow access to file URLs” is checked for extensions you need locally.

I hope this list was useful! Hopefully you learned something new you can use in your day-to-day accessibility testing.