I’ve been writing WordPress plug-ins for a while now — I launched my first plug-in a little more than 3 years ago. I’ve been involved in web site accessibility for about seven years. Naturally, when I started writing WordPress plug-ins, making them accessible was part of my goal. But accessible software extensions have two aspects: the interface, and the output: and I don’t have complete control over either.
Is it possible to make a plug-in with accessible output, guaranteed, every time? Is that compatible with a desire to provide flexible software which developers can use for a wide variety of possible needs from a design and functionality perspective?
What I’ve found is that I can unquestionably make a plug-in which is capable of creating accessible content. However, I’ve also discovered that in order to really make a plug-in flexible, it can’t have too rigid of an output: it needs to allow the user to customize the structure and content at a pretty significant level.
As a web site developer, this is certainly something I always want: whenever I find myself using a plug-in which doesn’t have built-in templating for the output, I can be pretty certain that I’ll be making edits to the core plug-in files. The HTML (HyperText Markup Language) produced is rarely what I really want. My conclusion from this is that if I want to create plug-ins which will be used by sophisticated developers, then they need to be very, very flexible.
The downside to this, of course, is clear: if you can change the output, you can break it. As a result, every one of my plug-ins which creates web site output has equal potential to be accessible or inaccessible: and I can’t guarantee the results. Additionally, the core content of the site can only be as accessible as the theme surrounding it — so even if the plug-in is configured with my defaults, that doesn’t guarantee any particular level of accessibility.
I’ve had to accept that. But it does mean that I’m constantly seeing implementations of my plug-ins which, while well-done in general principle, just don’t meet my ultimate wishes for accessibility.
But I wouldn’t turn back. I’d like very much to be able to enforce accessibility; but realistically, I can’t do it. There are too many factors.
My User’s Guide to My Calendar includes a short section on the principles of Accessibility; hopefully, a few people will gain from that fact. The fact is that accessibility requires education: you can’t force accessibility on somebody by providing accessible software unless you also take total control over the look, feel, and function of that software, and that’s not the way the web works. With education, you can help move people towards making their own decision to support accessibility in how they customize their software; so that’s what I’m hoping for.
So, what does it mean to write an accessible plug-in for WordPress? I can’t control the administrative interface entirely; because the fundamental interface is the WordPress core, and I can’t just evade that. I can’t control the output, in either structure or design; and even if I could control what exists within the parameters of the plug-in’s output, I can’t control what surrounds it.
So an accessible plug-in is just a plug-in which is able to used accessibly; a plug-in which doesn’t actually implement a specific lack of accessibility. Somehow, that’s a little depressing, but you take what you can get.
The overall lesson to take from this is that no plug-in is actually going to give you an accessible web site. But hopefully, it’ll give the possibility of an accessible web site.
Joe Dolson
@Ryan Yes — I reviewed a good book on WordPress plug-in development a few months ago: Read my review of WordPress 3 Plugin Development Essentials.
Ryan Bradley
Do you recommend any books on how to make plugins?
Tim Lawless
I’ve been looking for info on these type of plug-in for a while.
This helped, thanks!
Joe Dolson
Hi, Cliff – thanks for your comments. They do make it fairly evident that you didn’t read anywhere on this site beyond this article, but the thought is appreciated, nonetheless.
Cliff Tyllick
Hi, Joe!
In this post, you have come to recognize a different aspect of accessibility—the issues of accessibility we encounter when we deal with authoring tools.
From the standpoint of the developer, there are two issues:
How can I make this tool accessible to everyone?
And how can I help the people who use this tool create accessible content?
On a small scale, this is about a module that does one thing well. For the sake of having something simple to discuss, let’s say our module can be used to add images to a blog.
So first we would ask whether our module is accessible. It might call for the user to make a number of choices—what types of images they want to be accepted, image size, file size, and many other factors. To make these choices, the user would have to complete a number of form fields. Can the user reach each field with the tab key? Can screen readers recognize and announce each field’s label and, if it’s a list, the contents of that list?
To achieve these aspects of accessibility, we would refer to and try to conform with the Web Content Accessibility Guidelines (WCAG (Web Content Accessibility Guidelines)), which currently are in version 2.0. (I hope all your readers know of WCAG 2.0.)
Then we would have to ask whether our module helps all users create accessible content. If the user is placing images in a blog, those images might need captions, descriptions, and alt text.
“Might” is an important word here. There’s no way we can tell whether a given image needs to have a caption, a description, or alt text. It all depends on the context of its use. So we have to make it possible for our blogger to give each image a caption, description, and alt text—but we can’t force them to do so. By giving bloggers these choices, our module would help people create accessible content.
“But wait!” some readers are saying, “For accessibility, doesn’t every image need alt text?”
No, not alt text—but every image does need an alt attribute. So when the blogger leaves the field for entering alt text blank, our module should make sure that the image tag has an empty alt attribute: alt=””.
That might not be right for a chosen image. But the error would be the blogger’s. Our module would have responded correctly to the information given by the blogger.
So the best our module or any other authoring tool can do is to produce the right output for the information a user enters. It can’t force the user to give it the right information.
WCAG 2.0 does not address this aspect of accessibility and authoring tools. For that, you have to go to a different set of guidelines—the Authoring Tool Accessibility Guidelines (ATAG (Authoring Tool Accessibility Guidelines)). These guidelines call for an authoring tool to, first, be accessible and, second, as much as possible support authors in creating accessible content.
ATAG 2.0 is currently in development, and you can actually help move it along. The W3C (World Wide Web Consortium) Web Accessibility Initiative working group that is developing these guidelines needs examples of two successful implementations of each guideline. You don’t have to prove successful implementation of all of ATAG 2.0—just of any guideline that you feel your authoring tool implements successfully.
And they’re pretty flexible about the concept of an authoring tool. It could be WordPress alone, or WordPress plus your plug-in, or WordPress plus your plug-in plus two other plug-ins, and so on—whatever combination it takes to meet that guideline.
And you know what? Even if you fall short of meeting any of the guidelines in ATAG 2.0, testing your plug-in against those guidelines would give you clear goals for improving its behavior and performance with respect to accessibility. And it would help you document specific cases where WordPress (or another plug-in) is falling short of all you would like it to be as an authoring tool.
Good work—and good luck!