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 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.

At the end of October, I took a very needed vacation. Naturally, I couldn’t just go on vacation, so while I was taking a break I developed two new WordPress plug-ins: My Content Management and Content Progress.

These are plug-ins designed primarily for developers, really — although a novice user can probably get something out of them, even so. They aren’t terribly complicated; they’re just designed as plug-ins which are used for developing new web sites.

About My Content Management

The first of the two, My Content Management, is a tool which creates a suite of custom post types intended to fulfill a variety of special content needs which are common to many web sites. Obviously, these can be done using normal pages, as well — or dedicated plug-ins for the specific content, but I like to have the option to use a standard, common interface. Using this plug-in, you can have an FAQ, Testimonials, Staff Members, an artist’s Portfolio, etc. — all using the same interface.

If you normally develop web sites and then train your client’s to maintain the site themselves, it’s a tremendous help to have a standardized interface for all the content they need to add!

The plug-in features highly customizable templates for three different views of each content type; shortcodes to display the content; widgets for lists of content; special custom field support for the content; and custom taxonomies for each content type.

About Content Progress

This is really a simple plug-in, but particularly useful during the early content development stages for any web site. Content Progress adds a flag to the posts list view which allows you to easily pick out which pages have not been completed. For large sites, this can be particularly handy when you need to keep track of what has and hasn’t been taken care of.

There are two automatic labels: marking pages which have no content or which have very little content, since these are common indicators that content still needs to be completed. Since these are obviously not a complete picture of the site, there are also two manual flags, to specifically mark pages as completed or incomplete.

Hopefully, developers and content creators will find these plug-ins useful!

• Download “My Content Management”
• Download “Content Progress”