A Focus on Accessibility
- The Theme
- The Plugins
- The Developer
Theme Accessibility Remediation
First we have to evaluate if a theme has taken into account accessibility at all. Sometimes a theme can be modified through a child theme to add basic functions such as a “skip to content” link. Sometimes themes do not lend themselves to be modified in this way because there is no clear identification of where the content starts and ends.
Another problem is when themes are “packaged” with pre-built layouts and plugins which are not accessible. This makes it much more difficult to isolate and repair elements or remove them because you are breaking something apart that was tightly integrated. In this case we often recommend re-building the website. The KISS principle applies here. We believe that a theme should not be dependent on specific plugins.
As part of our accessibility remediation efforts we have worked with theme developers to improve their products. In the case of Beaver Builder Theme (which we use on some websites) the staff have been very responsive and make accessibility improvements regularly. We recently asked a theme developer about accessibility for a theme that is sold on Themeforest. He stated in an email to me that they have no intention of improving accessibility. This was quite a surprise to me considering the theme in question was considered “one of the best” in Themeforest and considering the ongoing lawsuits over accessible websites.
Important Note: we do not use Themeforest themes but we provide tech support for our WPTechGuru clients who happen to have Themeforest themes on their websites.
Plugins and Accessibility
Plugins are powerful tools that usually are designed to make things easy on the front end or back end including adding impressive features to a website. Many plugins use code in ways that are not accessible or don’t consider accessibility.
We notice this in particular with animated elements such as slideshows and carousels. In general we recommend against slideshows and carousels because they are a bad practice for all types of users, disabled or not. A simple rule is to be suspicious of anything that isn’t text and image or a button. Beyond those elements you can easily run into trouble. The quickest way we can tell if something is inaccessible is to use the tab key to tab through the web page – if the unusual elements don’t work when tabbing, they are inaccessible. Of course there is way more to consider than whether tabbing through a website works but it is a quick way to identify non-accessible features.
The Crucial Element: The Web Developer
Remember that the web developer chooses the theme and the plugins. They have the ultimate responsibility to consider accessibility. From there, even with wise choices of a theme and plugins, the developer can choose what to do with those elements. Even in CSS you can run into trouble as we have in the past. Education is the key. The more you work to ensure the websites you build are accessible the more you learn and understand. That way everyone is better off.
Outside Elements Fail Accessibility Tests
This post wouldn’t be complete without mentioning the zillions of things that can be embedded in websites, Maps, Videos, Calendars, Apps, Calculators and so much more. They are often called widgets and in our experience the vast majority of these types of embeds are problematic at best. The simplest items to fix are things like Titles and some basic CSS. This places a burden on the developer to login to the applications controlling these embeds and modifying the code. This extra work adds to the hours involved in remediation. Often these widgets are so badly designed they cannot be remediated without asking the app developer to make changes. We have no control over whether these changes are implemented.
We never dreamed we’d focus on accessibility until we realized how it is so aligned with our values AND we enjoy the challenges of learning to do things in a different way to make websites more accessible than ever.