Mr. Borghi said that he was happy to make his gallery’s website accessible and that he was able to do it with a free widget from WordPress, which added narration, larger fonts and keyboard navigation. But he said he was not sure if that made him fully compliant; the lawsuit against his gallery is still pending.
Mr. Borghi is not certain whether adding this unidentified WordPress plug-in made him fully compliant – but I can readily suggest an answer: No, it didn’t.
Before delving deeper, I have to acknowledge that nobody can decisively answer the key question: whether or not Mr. Borghi’s website is accessible in the eyes of the ADA. The ADA has not provided guidance that defines whether or not a website is accessible, so this answer isn’t available outside of the courts. However, unless this website was already mostly accessible, adding these features won’t make a difference.
Adding narration makes absolutely no difference. If the site has been created in a manner that supports screen readers, then they already have the support they need. If it doesn’t, then the narration widget still won’t have access to missing information: images without alternative text, buttons without text labels, or layouts that take content out of sequence.
Adding the option to increase font sizes does equally little. Every browser allows you to increase the font size. Users who need more significant increases have access to zoom tools that provide that service. With your browser, you have the added bonus that your preferences carry across multiple sites – and they aren’t dependent on cookies to function.
The one area where the widget might actually be helpful is in adding keyboard navigation – if it does this successfully. However, from a practical understanding of what this is likely to mean, I suspect that it is incomplete. While a widget can add tools like skiplinks or ensure that focusable elements on the page have a visible indicator, there’s little they can do to fix an issue where actions are being triggered by clicking on a div.
Accessibility Toolbars are not very useful
I’m fully aware that I have released a tool that includes an accessibility toolbar. My own plug-in, WP Accessibility, includes a minimal toolbar. And I sincerely regret including it. It’s a pain to support and is by far the least important feature of the plug-in. I envisioned the plug-in and the toolbar as being a stopgap tool – an emergency tool that sites could install to improve their situation while they work to fix the underlying problems.
This was naive.
What I’ve found to be the reality is that people install the plug-in and leave it in place permanently. Many people appear to consider the toolbar to be the primary feature of the plug-in, where I consider it to be the least important feature.
The important thing about any accessibility plug-in is having a good understanding about what problems are being solved. When we’re talking about font size changes and narration, these are features that already exist in the browser or in assistive technology – adding this to your website does almost nothing. It may help a small number of people in specific situations, but that’s the limit.
Some features are more significant, however. WP Accessibility, for example, contains a feature that automatically labels the native WordPress form fields. Many themes omit the label on search forms and comment forms – WP Accessibility can put those back. This works only because these are native fields, and have a known input name. I can’t do this generically, because there’s no way to identify an appropriate label for most fields. This isn’t a feature that any browser or assistive technology will do themselves.
What should you do instead of using an accessibility toolbar?
Start by assessing the accessibility of your site casually, for yourself. Test it at WebAIM or using Tenon.io. When you’ve identified some errors, start sending requests to the people responsible – ask the theme developer to fix their issues. Ask the person who built your website to fix issues.
Web site accessibility will only be broadly implemented if everybody who builds websites or web tools understands what they are personally doing wrong. Tools that try to fix the results are just a band-aid; they don’t fix the problem at the source. Hiring website accessibility consultants or specialists to fix your site will only fix your site, and have no impact on the larger web.
Please – start by asking people to fix the problems they created. If you’re being sued, it’s probably because somebody sold you a broken website.
Have something to contribute?