This morning, I had a conversation that highlighted for me one of the challenges WordPress faces in shaking off the label “not accessible”. It was a conversation with a large university system that was considering deploying WordPress as a resource for faculty blogs, within the institutional requirements that the site had to comply with WCAG (Web Content Accessibility Guidelines) 2.0 at level AA.
They’d had the test installation reviewed by an expert blind user with JAWS, who had come back with a number of problems, including:
- Problems with navigation and information sharing with the content slider
- Problems with user feedback in the contact form
- Problems with missing alt attributes
These weren’t the only problems cited, but that doesn’t change the nature of the problem.
The problem is that none of these are characteristics of WordPress. The slider might have been from the theme, or from a plug-in. The contact form was probably a plug-in. The alt attributes? A user input problem, ultimately.
One of Drupal’s advantages in accessibility is that it does provide a core mechanism for generating forms – and while not all forms in Drupal are generated by Drupal core, many of them are – at the minimum, a basic contact form is almost certainly something coming from core. That means that Drupal is able to guarantee that an accessible form is available, even though it’s still the user’s responsibility to implement it effectively.
WordPress doesn’t do this – whether that’s good or bad is a separate question, but it’s unquestionably the truth. As a result, WordPress can’t take responsibility for most form behaviors on a WordPress web site.
But the user experience interacting with WordPress is mostly based on the front-end — and if the front-end experience isn’t accessible, the first entity to receive blame is the content management system, even if the theme or a plug-in is the actual cause of the problem.
This is one of the reasons for accessibility-ready themes, and why we’d ultimately like accessibility to be a required characteristic of themes hosted by WordPress.org. User confusion is never a good thing — whether that’s a confusion about how to complete a process or identifying the source of problems.
Contact form plug-ins in WordPress are rife with problems. The two biggest plug-ins for contact forms are probably Contact Form 7, in the free realm, or Gravity Forms on the premium side. Both plug-ins have their problems. Contact Form 7 can be implemented with accessibility quite easily: the primary problem is with the default form. If you use the default form, it’s a disaster; you have to know enough HTML (HyperText Markup Language) to associate a label and an input field in order to use it correctly. While this is great for experienced developers, it also means tens of thousands of amateur users setting up inaccessible forms.
Gravity Forms, because it generates more of the HTML for you, has slightly better default output – but it’s still a long ways from perfect. As a result, while your default forms will be more accessible than those from Contact Form 7; the barrier to making a truly accessible form is even higher. There’s a plugin specifically to improve accessibility in Gravity Forms, but it’s hardly ideal to need to install a second plug-in to fix the first.
Missing alt attributes are 100% the responsibility of the content author, with the exception of places where WordPress or a plug-in outputs an image on behalf of the content author — such as in an image gallery or a content slider. However, even at the very best, WordPress shouldn’t do anything more than strongly encourage users to add text for an alt attribute – because it is entirely valid for an image to have an empty alt attribute, and WordPress cannot possibly detect whether that’s the case for any given image.
Content sliders or, “the UI of the devil”
Content sliders, or carousels, or whatever you choose to call them, are universally bad for usability and for accessibility. There are ways of making them “accessible” (and I put that in quotes intentionally), but they’re essentially just a horrible way of communicating information – so the best case scenario is still a bad experience. Yes, you can make it accessible – but the key to making a content slider accessible is to ensure two things: first, that the content is available to the user, and second, that it isn’t forced on them. Because, like most visitors to your site, people with disabilities don’t want to look at the content in your slider.
If you’re talking about the front-end experience, WordPress core truly has very little direct impact on the accessibility of your site. It’s certainly not none — there are core widgets and there is some core HTML output in areas like comment forms and menus, but almost all of that is just straightforward, traditional HTML. If HTML is written correctly (as in the WordPress core output), then the problem isn’t with WordPress – it’s with whatever CSS (Cascading Style Sheets), JS, or error-prone HTML is added by other resources.
WordPress is amazingly extendable – and while that makes for an ecosystem that’s vibrant and thriving, it comes with significant risks, as well.