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 Forms
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
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.
In Summary
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.
Adrian Roselli
I’ve worked in the content management space for more than 15 years, and helped build our own CMS (Content Management System) starting in ~2000. I have struggled with the issues you cite many times over in many different CMSes. I truly understand that implementation matters.
Having spoken at a few WordCamps now, I consistently see WP site developers and authors who don’t even understand there are issues. I react as strongly to suggesting authors are to blame as I do to suggesting the same of users. That may not have been your intent, but I have a hair trigger.
I think the WP Accessibility plug-in is great, I think the Cities Project is commendable, I think that requiring themes to be accessible is ideal. I think there are lots of great plug-ins that address so very many issues and your work (and the work of others) on them is excellent.
Sadly, the average WP dev/author knows none of this, and it’s typically not their fault.
Hence, my rantiness.
Thanks for the response.
Joe Dolson
First, I agree with you.
This post came out of a conversation where these were the three top concerns they wanted an opinion on; I haven’t seen the report, and don’t even know whether they tested the admin.
My point is that when you cite these issues as the primary concerns about WordPress, it isn’t enough information to know where to point the blame. Implementation matters.
I agree that WordPress should include a contact form, and that the enforcement and encouragement to use an alt attribute should be improved – but the fact that these issues are lacking in a website is only evidence that the implementation is poor, not that the application is inherently flawed – that requires further investigation than a front-end assessment can provide.
Ultimately, my point is that you can’t look at a site and judge that the tool used to create it is necessarily the source of the problems.
I apologize if I gave the impression that I think that the implementation of alt attributes or contact forms in the WordPress core are adequate.
Adrian Roselli
You cited three problems, with acknowledgement that there were more reported. I am curious what the other problems were (as in, how many are about the admin interface versus terrible developer implementations).
Of the three you mention, the carousel one is easy to dismiss as not necessarily a WP issue. Even if there weren’t plug-ins, developers would still implement terrible third-party solutions regardless of platform.
I agree that third-party contact forms are terrible, but that doesn’t absolve WordPress. If anything, it tells me that WordPress core should include a basic form building tool. I consider that a clear miss for a product already filled with forms (comment fields) and notifications (comment alerts).
I strongly (I’m almost apoplectic) disagree that missing alt attributes are 100% the responsibility of the author. I think the default WP image library does a terrible job of managing author expectations. It auto-populates fields with useless, often problematic content (file name as title?), and does nothing to warn or guide users.
Authors I have trained to use alt see some text with the image, assume it’s handled (or worse, make an edit to the change the existing text without moving it to the correct field), and call it done. Dismissing this known issue as author-only is a cop-out.
WP could move alt to the first field (instead of the problematic title, and not below caption), make it more prominent, provide a visual cue with an info bubble, and even throw a (configurable) warning when left blank. Using the title in place of the alt when left blank kills the ability to even let an author intentionally leave an appropriate blank alt without also understanding how title is (mis-)used.
This should be core, not via a plug-in, given how few authors even know about accessibility.
When I consider W3C (World Wide Web Consortium)’s priority of constituencies (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies), I feel the content author comes before the product developer (implementor). As such, when the product knows there are issues with which authors continue to struggle, then the product should remedy.
At the very least, it mitigates the need to write posts in defense of the product.
Joe Dolson
That’s absolutely true, and it happens all the time – and WordPress does have a responsibility to provide the possibility for both accessibility and security, but can never guarantee either. Thanks for commenting, Amanda!
Amanda Rush
These are almost exactly the same artuments you could make when it comes to security. WordPress core is reasonably secure, and yet whenever there’s a vulnerability with a plugin, WordPress gets the blame. See the recent stuff on WPStats I think it’s called.