Let’s check our work! Whether you created something from scratch, or you are revising an existing project, it’s helpful to have a way to analyze a project for accessibility. Fortunately there is a very handy tool available from WebAIM that will do the bulk of the analysis for you!
What features does a webpage need to have to be accessible? This is where we are putting everything we’ve learned together:
- Content should be formatted with headings
- Images should have alt-text
- Text and images should have sufficient contrast
- Hyperlinks should be descriptive words, and each hyperlink should appear only once on a page
- Any lists should be formatted with bullets or numbers
- If there is audio or video, it should be controlled by the user and have closed captioning
As always, there’s no way to automate inclusion of most accessibility features! It takes human judgment to mark up content for accessibility. The same goes for analyzing accessibility. The free tool listed below will do the bulk of describing a page’s accessibility, but it’s up to you to decide if it’s done right and what’s missing.
WebAIM WAVE
Once you have a lot of practice adding in accessibility features, you get a good sense of how complete your efforts are. In addition, you can use WebAIM’s free WAVE tool to check accessibility of websites! You can copy and paste your URL into their site, or, they have a handy plugin for your browser so that you can analyze any website you visit. It will provide you with a summary and detailed report of the accessibility features on any given webpage.
The WAVE tool may be used on any public webpage. If you have a private page, like a Canvas course, install and use the WAVE extension in your browser to analyze. You can even use WAVE on Articulate Rise and Storyline projects!
This video demonstrates use of the tool. Read on for more information.
Using the WAVE tool will produce a report that will pop up next to your webpage being analyzed. For this example, I used University of Phoenix’s home page. Check out the WAVE report for yourself!
The report defaults to the Summary tab. You’ll see an overview of errors, alerts, and more. This default view can be a bit misleading, as your webpage probably isn’t as inaccessible as it might look at first. This report is generated automatically and WAVE’s code does its best to discern accessible features, but it’s not always perfect.
Interestingly, about a third of the errors listed above are just missing alt-text – this is very easy to fix! A full half of the errors are “broken ARIA references.” This takes a little more explanation, but isn’t something you can fix as a non-coder. If your page has a lot of ARIA errors, you’ll have to contact your IT department, or choose a different template for your website if it’s a DIY project.
Summary
There is a lot to look at in the Summary tab. If you are running this on your own content, don’t panic just yet! Take the time to view the details of each item and get an idea of what’s going on. Errors are your priority. There may be further problems flagged in alerts, structural elements, and features, but these mostly list well-formatted accessibility features.
Select “view details” or head to the Details tab to dive in.
Details
This is where you see the full report! Again, don’t panic. There may be a lot here to digest, but oftentimes you can make one overall change that will fix several problems at once. Like text color contrast, for instance. If you change a font color in your template/theme/master, it would change all font colors at once to be accessible, potentially clearing many errors all in one go.
As you review the details, you may be unfamiliar with what the report is trying to tell you. Select the little “i” to learn more about each item and to see further resources. Select the Details tab to return.
- Errors
Take a look at these first. Every error is color-coded in red. WAVE will check if each image has alt-text, but not the quality of the alt-text because that takes human judgment. If you see form label errors, you’ll either have to contact your IT department or go into the code yourself and get a little messy. - Alerts
Coded in gold, alerts are akin to errors. For instance, your images might have alt-text, but there may be two or more images with the exact same alt-text. This is a no-no. Every image should have completely unique alt-text, just like every hyperlink should be unique and only listed once. The thought here is that you are wasting a person’s time if they are using assistive technology to browse your page and they have to wade through redundant content. So that’s largely the kind of thing you see in Alerts, things that are technically accessible but practically, they are a problem. Alerts will also list your redundant items as well as issues with text formatting and other items that you should double-check. - Structural Elements
Coded in blue, structural elements refers to your headings and lists. It gives you a breakdown of how each heading level is used in your document so that you can see if you’ve structured the content correctly. It points out where each ordered and numbered list lies. You should scan this section to be sure it looks correct, but you generally don’t need to go through it really thoroughly. - Contrast Errors
Astoundingly, the University of Phoenix page doesn’t have any contrast errors! Also coded in red, when present, you’ll see where text color has insufficient contrast against the background. If you have a lot of text that lacks sufficient contrast, you may be able to change the font color in your overall template to fix it all at once. - Features
Coded in green, features point out accessibility features that are present as well as more accessibility features that should be double-checked. For instance, it will flag any alt-text that is null, that is, the code presents as alt=””. There should be alt-text present in between the quotation marks in the code IF you want the user to know about it. If the image is merely decorative, the alt-text should be null because then screen readers will skip over it. Features points these out so that you can double-check to make sure they shouldn’t have alt-text. Features will also point out all of the other things that are accessible in your document. Generally you can just quickly scan this section and not worry about what it lists. - ARIA
ARIA is supplemental web code that was developed to help make webpages that were coded in HTML4 more accessible. The current standard version of HTML code is HTML5, which includes many of the accessibility features that ARIA was meant to correct. But ARIA can still be used to fill in accessibility gaps. In this U of Phoenix example, we can probably deduce that the hundreds of uses of ARIA is dated and unnecessary if the website were fully updated to HTML5 and cleaned up to remove redundant ARIA labels. However, these ARIA errors are reducing accessibility. Bottom line: Contact the IT department. You aren’t going to be able to fix ARIA if you are not a coder. Here’s a great introduction to ARIA and how it can help (or hinder!).
Reference
When you select the little “i” next to each flagged item, details will appear in the Reference tab. Your place will be saved when you pop back over to the Details tab.
Order
A screen reader user proceeds through the page in a linear order. This tab shows you what that order is. Ideally, the most important information should be first, as well as features that allow the user to skip menus and navigation. Skim the order to see if it makes sense. Sometimes content that is very unimportant can be moved down in the order. Again, the idea here is to create a positive experience for a screen reader user. Don’t waste their time!
Structure
This section of the report gives you a map of how the page is structured. In Structural Elements, you saw how many of each heading level was used, as well as how many lists and things there were. Now, you can visualize how it all goes together. Like Order, make sure that this structure makes sense. You might see the word “Region,” this refers to the various sections of a webpage, like the header and footer, or the main content. The University of Phoenix example has far too many regions, it’s quite cluttered and would be very difficult for a screen reader user to navigate.
Contrast
Here, you’ll see a repeat of the contrast errors from the Details section, as well as a tool that allows you to check colors for contrast. This isn’t a user-friendly section. You’ll likely have to go into the editing mode on your webpage to see what colors are in use so that you can adjust the contrast.
Summary
If you haven’t already, bookmark the WAVE tool, and add the extension to your browser!
Remember that you’re not going to reach perfection when making your content accessible, but following the principles that I’ve outlined will get your content to where it needs to be. Reuse the WAVE tool to check your work as you revise your webpages. It’s normal to have an inaccessible bug or two that you just can’t figure out. Let it go! As long as the overall experience is positive for your user, it’s fine.
WAVE is a fantastic tool that should be part of anyone’s accessibility toolkit. And as always, the more you work on including accessibility features, the easier it gets!