Recently released, the wA11y plugin consists of tools to check and correct your WordPress site’s accessibility. (The name is derived from a11y, the shorthand way of writing accessibility, with “w” representing Web.)
The plugin was developed by Rachel Carden, a software engineer at Disney Interactive and accessibility advocate.
I decided to give wA11y a spin to see what it could do.
The plugin is still in version 1.0, so I’m expecting more features to come.
What’s in the Web Accessibility Toolbox?
It currently consists of 2 main tools.
For each, you’ve got the choice of enabling them for particular user roles. If you only want admins to use them, you can specify that in the settings.
Enabling tota11y adds x-ray vision to your site! Well, not quite, but it puts some aspects of your site’s accessibility under the microscope.
A small glasses icon is added to the bottom left of your page. Clicking on this reveals 7 accessibility testing options – one experimental.
For each issue, the relevant code is highlighted, and there are suggestions on how to fix it.
Twenty Fourteen isn’t as accessible as I thought…
When testing with tota11y the tool spotted that there was a bug in the heading display in Twenty Fourteen theme, even though the theme is labelled as accessibility-ready.
There’s a jump from the Heading 1 “Previous post” to Heading 3 “Leave a reply”. Heading levels are not supposed to be missed.
There’s actually two H1 tags in that post markup, too, which is not good for SEO!
When I tested the same post again using Twenty Sixteen, there wasn’t an issue.
Upping the colour contrast
Choosing the right theme is an important part of making sure your WordPress site is accessible. Some are more so than others.
One feature in the contrast checker I really like is that it gives suggestions for improving the contrast.
The Lontanotheme has a number of areas of poor contrast, probably too many to make it a suitable choice for an accessible site.
But tota11y suggests how darkening the green will meet the guidelines, and checking the preview box shows you what it would look like. Totally awesome! I haven’t seen this feature elsewhere.
This would be very helpful to theme developers.
Is your alt text correct?
If you follow the advice in my previous post about inserting alt text when you upload images then you shouldn’t have a problem.
There are possible plugin issues, though.
I found with the YourChannelplugin tota11y complained of missing alt text.
The plugin creates YouTube video galleries with thumbnail images and video titles.
As far as I’m aware YouTube doesn’t allow you to add alt text to video thumbnails, but the
<img> tag for them has no alt attribute at all.
So I’m not sure who’s responsible for this particular accessibility fail.
Lame link text
Tota11y sensibly highlights “click here” link text as making no sense out of context.
Surprisingly, it also didn’t like the “About” link in my menu. I’d have thought it was obvious it was “About the site”.
Read this SitePoint article for best practices on accessible links.
wA11y’s Tota11y checks wp-admin too
Notably, tota11y can be enabled on the back end of the site, meaning that you can test the accessibility of plugin and theme options.
This is a very useful feature in identifying theme and plugin accessibility weaknesses.
I had a look at WAVE in my article on accessibility testing tools, so I won’t dwell too much on it here.
It’s worth noting that WAVE can only access public pages, so you can’t use it on a local install of WordPress.
WAVE checks some features differently from tota11y
If you use both tota11y and WAVE, there’s a fair bit of overlap in what they check, but I did notice some differences.
For example, tota11y checks for the presence of form labels i.e if the
<label> tag is present.
WAVE checks the
for attribute of the
<label> tag as well. This tests if the form label is correctly associated with the form control.
The standard contact form from Contact Form 7 passes tota11y evaluation, but not WAVE!
To correct this, you need to use the plugin Contact Form 7: Accessible Defaults, which produces the correct markup to pass the WAVE evaluation.
The standard form code is:
<p><label> Your Name (required)<br /> <span class="wpcf7-form-control-wrap your-name"><input type="text" name="your-name" value="" size="40" class="wpcf7-form-control wpcf7-text wpcf7-validates-as-required" aria-required="true" aria-invalid="false" /></span> </label></p>
The accessible form code is:
<p><label for="your-name">Your Name (required)</label><br /> <span class="wpcf7-form-control-wrap your-name"><input type="text" name="your-name" value="" size="40" class="wpcf7-form-control wpcf7-text wpcf7-validates-as-required" id="your-name" aria-required="true" aria-invalid="false" /></span> </p>
Subtle, but it makes a difference.
Who is this plugin for?
Unlike other WordPress accessibility plugins, wA11y doesn’t automatically fix the issues found. You need to do that yourself, or alert the relevant developer to do it.
While it could be helpful for end users, I think wA11y is best geared towards theme and plugin developers and accessibility testers.
I see it as a useful checking tool to make sure that accessibility standards are met along the development path, and after a site is launched and further content is added.
Of course, that depends on designers and developers knowing accessibility guidelines to begin with, and WordPress users being trained too!
Want to support wA11y?
wA11y.org is a community site with the aim to improve web accessibility globally.Support #wa11y - a new initiative to contribute to web #accessibility via info, education, resources & tools https://wa11y.org/ Click To Tweet
You can join in with the project in a number of ways:
- help to develop apps
- blog for the site
- write documentation
- carry out testing.
If you’re interested, join their mailing list to keep in touch.
Over to you
What do you think – will you be making friends with the Web Accessibility Toolbox?
Loved the post? Please share and spread the word.