So you’ve been learning a lot about accessibility lately, but now you want to check your site yourself and see where you need to improve. How do you go about doing that? It’s time for an accessibility audit! In this tutorial, I’ll show you the ropes on a basic accessibility audit that will get you on the road to having a more accessible site.
As you’ll recall from my overview series, an accessible website is perceivable, operable, understandable, and robust. Testing to make sure your site hits all four pillars of accessibility does not involve coding, so don’t worry. We may install a Chrome extension or two, but you’ll thank me later. Let’s get started!
NOTE: This tutorial assumes you know how to use the Chrome Inspector, or whichever browser’s basic developer tools are provided.
Start with perceivable because if your site can’t be perceived by the user, they don’t know it exists. Here we will focus on three things: text alternatives, captions, and color.
For every image on your site that’s more than decorative (meaning it’s a vital part of the information, not just an enhancement), the image should have an
alt attribute. You can check this by inspecting the source code of the image and looking for the attribute. If it’s there, great! Now we need to make sure the attribute’s value is useful. An alt attribute should describe the image in a way that informs visually impaired users. This is NOT an opportunity to stuff SEO keywords into your site. Make your description short, to the point, and helpful. Longer descriptions should be saved for the site content itself.
Going along with images is video and audio content. In both cases, you’ll need to provide some kind of captioning or transcription of the content. Your videos should have closed captioning enabled, or be pre-captioned. Testing for this is as simple as starting a video on your site and checking for captions.
Lastly, we need to test our colors. To do this, we’ll install a Chrome extension that enables a grayscale mode. Once installed, load up your site again and turn on the extension. Note the areas that are hard to read. These are where your problems are from a contrast perspective. From there, disable grayscale and use the Snook color contrast checker to check your scores. You’ll need to use the inspector to grab your hex values if you don’t have them handy. Remember, anything less than a 4.5 (or 3.0 for large text) is an issue.
The next step is to make sure the site is operable. This means we’ll be testing keyboard functionality. To do this, open your site. Once the page is loaded, hit the tab key. What happens? Hopefully, a skip link pops up. If not, you should at least have an outline around the first link on the page. Ideally you’ll have custom-styled
:focus states, but the bare minimum should be what the browser provides. From there, keep hitting the tab key to make sure you’re going from link to link in the order they appear on the page. If your focus keeps jumping around, you’ve got a tab index problem that needs to be resolved. Form plugins are often the culprit here.
Next, we’re going to check your site to make sure it is readable. After all, if a user can’t read your content, what’s the point of having it? The requirements here are pretty simple: can the language of your site be determined with code? To check, open up your inspector and look at the main
<html> tag. Does it have a
lang attribute? If so, you’re clear. You’ll also want to make sure any segments that are in a different language have the lang attribute applied.
There are other AAA level checks on readability, but those are beyond the scope of a basic audit. In general though, you’ll want to keep your content at a 6th grade reading level unless your target audience is of a higher level of education.
The other important aspects of your site’s understability revolve around error messages and changing of context. More specifically, the lack thereof. When a user gives focus or activates an input, a significant change should not occur. The page should not jump unless the user is warned in some way (an arrow icon, helper text, etc.). These are the kinds of things you would have noticed when testing with the keyboard.
When testing your forms, the same can be said of error messages. Errors should be displayed to the user clearly and stay on screen so they can correct the errors. This is something even big websites get wrong all the time. They forget to bring focus to the part of the page that has an error, or at least mark it somehow. Test your forms for errors and make sure the messages are clear. Using a solid forms plugin will help with this a lot, but don’t rely on the plugin to do all of your work. You’ll also want to make sure you’re not just using a color (typically red) to signify an error. The actual text “Error” is very important, especially for people with red/green colorblindness.
Beyond errors, your forms and inputs should have clear instructions. Go through each input on your site and make sure it is abundantly clear what the user should do. For example, search forms should have something besides a magnifying glass. A simple “search” label will suffice. Make sure your users know what to do with interactive elements. Never assume.
Lastly, your site needs to be robust. What this means is the site is usable with assistive technologies such as screen readers. If your site is well formed with HTML, you should be okay. Just keep in mind that some modern browsers, including Chrome, will fix basic HTML errors, or at least attempt to fix them. The quickest way to test the robustness of your site is to load up the site in Safari and enable VoiceOver, a built-in screen reader. If your site doesn’t work, you’ll need to address those issues.
This audit tutorial was quick, but that’s the point. It doesn’t take that long to make sure your site is accessible, and the tools required are minimal. The important thing to remember is that you want to put yourself in the shoes of someone who doesn’t have the abilities you take for granted as an average user. Keep that mindset, and your audits will ensure that your sites are more accessible.
In case you missed it, check out this series on accessibility: