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”

In point of fact, My Calendar version 1.9 is ready to go. It’s packaged up, ready to be shipped out. (Well, promoted to the subversion repository. Whatever.)

However, I’m not ready to launch it yet — and this is just because I’ve been very short of time recently, and I don’t anticipate this changing soon. I don’t believe that there are any major bugs in the release — I’m sure there are small ones, despite the time I’ve spent on testing, but probably nothing earth-shattering. However, I have to be realistic — I don’t know this for sure. And because of that, I need to delay the full launch. This isn’t because I’m worried about the possibility of problems, particularly. Rather, it’s because on the off-hand chance that there are problems, I simply don’t have the time right now to be able to deal with them responsibly.

That’s a worrying position – if I launch, and there’s a major problem, I may not be able to fix it promptly. No matter how confident I am in the preparation of this version, that’s clearly grounds to delay. Unfortunately, I’ve been delaying for a long time; partially because I keep adding new features, and partially because I’ve been too busy for a while.

So I’m making this available here, now — version 1.9.0 can be downloaded now. I’m launching it here, instead of through the WordPress repository, because I know that many, many fewer people will get a hold of it here. This means fewer potential problems, and it’s much more likely I’ll be able to deal with any problems responsibly.

Since you don’t have easy access to the changelog, like you would at WordPress.org, here are the changes which apply to the new version:

Additions:

• template editing for list, grid, mini, and single event output.
• pop-up box is now draggable.
• date format option for grid mode, week view.
• templating for details link text.
• templating for event URL link text.
• location filtering from shortcode.
• image upload option for events
• day class to calendar date headings and cells
• individual instances of repeating events can be edited
• feature to add multiple occurrences of an event simultaneously. (concept from Dave Heitzman)
• feature to mass edit information for groups of events (concept from Dave Heitzman)
• stored URL for locations (contrib by John Colvin)
• recurring daily events on weekdays only (based on contrib by John Colvin)
• optional templating for all event output formats
• individual event occurrence iCal export
• numerous additional template tags
• Option to use custom location filter fields as data control
• Shortcode to generate list of saved locations
• Network administrators can control whether sub-site calendars contribute only to a central calendar, only to their own calendar, or whether site administrators can make that choice.
• Upgrade notice information in dashboard for future upgrades.
• implementation of WordPress text diff to compare your styles and scripts against my current released versions
• Option to skip a defined number of events in upcoming events lists.

Bug fixes:

• jump box was displaying in week/grid view.
• some potentially repeatable IDs (code validation).
• ‘Administrators see all options’ did not work.
• Fixed timestamps on main calendar objects
• Squashed e_notice errors.
• category limiting did not work without permalinks due to GET variable conflict with WordPress core
• Missing nonce in database upgrade routine
• Mini calendar simultaneously displayed single event view when visited.
• Link generation for details view did not work if calendar link parameterized
• Issue with weekdays only calendar if day of week set to start on Sunday
• Issue with retrieval of user-specific settings
• Issue with accessing styles and javascript if My Calendar installed in non-standard directory.
• Problem in Today’s Events widget when Holiday restrictions are enabled.

Changes:

• replaced all default icons with 24-bit transparent PNGs
• jumpbox output to automatically scope to the oldest dates in the database.
• iCal output to output event for complete current month
• RSS output to prioritize newly added events
• holiday skipping/fifth week customization moved into event manager function
• new ‘close’ icon for pop-up box; added close icon and scripting to mini calendar pop-up
• copy in several places; updated template tags.
• location lists sorted by location label (contrib by John Colvin)
• Eliminated calendar heading option
• default style resets no longer stored in global variables, instead stored as files.
• Map links now trigger the driving directions dialog in Google Maps
• New default stylesheet, refresh.css

WordPress 3 Plugin Development Essentials

by Brian Bondari and Everett Griffiths

Read more about this book at Packt Publishing » or Buy it at Amazon

At root, this book is an excellent overview of the techniques and issues which will be encountered by any developer — however experienced — when they are authorizing a plug-in using the WordPress plug-in API in WordPress 3. In particular, I appreciated the emphasis on organization and coding best practices. I’ve worked with plenty of plug-ins, and there’s a lot of ugly, unmaintainable code out there. (And I’ve written some of it, too!) The fact that anybody looking to develop a plug-in who uses this book as a major reference will also get a guide to some best practices in writing software is a definite bonus.

The authors are very realistic about the limitations and benefits of the WordPress plug-in system. They observe that WordPress has a great deal of flexibility when it comes to coding style and organization — and the result is that there’s a low resistance to entry. Great for beginners, but it does mean that trusting the code you find is something you shouldn’t do blindly. Clearly the authors want to emphasize that anybody looking to begin developing plug-ins should give some significant thought to the sustainability and quality of their work. Kudos to them!

The book doesn’t cover an enormous number of different API functions, but it does give a good overview of the key hooks that are needed to get started programming for WordPress. Given the scope of what can be done in WordPress, it’s really a better solution to solidly introduce some of the core techniques rather than try and cram a huge number of concepts down the throats of their readers.

I found the systematic approach taken by the book to be extremely effective — I appreciated that the book intentionally had the reader introduce common errors into their plug-ins. Having encountered most of those issues by accident somewhere along the line, it’s tremendously valuable to already have been made aware of some key elements.

I do think that this is a good book, and very worthwhile for the beginning plug-in developer. There are a few additional areas which I would have liked to have seen covered, however.

Although the book is very thorough in addressing programming best practices, it doesn’t address the quality of output code at all. Valid HTML, consistent use of elements, semantics, and accessibility are all issues which deserve a significant mention in the programming of a WordPress extension — however easily the plug-in can be maintained, if it doesn’t produce high-quality output, this can be a major disadvantage for the plug-in. It is very dissatisfying to install a plug-in which does exactly what you need it to, but produces output which can’t easily be styled or doesn’t meet the standards required for your web site.

Nonetheless, there are no other issues which I felt were truly missed — the book is well-written, thorough, and methodical. I can highly recommend it to anybody looking to start authoring WordPress plug-ins.

Note: although this review was not paid, I was provided with a free review copy by Packt publishing in exchange for the review. It was definitely a worthwhile trade!

As an accessibility consultant and passionate standards advocate, I’m generally in the position of appreciating the concerns of the minority. As a WordPress plug-in developer, I have a much harder time with it. In fact, as a WordPress plug-in developer, I find the vocal minority very, very frustrating.

So I’m just going to whinge a little bit. You can stop reading now if you’re going to be a dick about it.

I recently released a new version (version 2.3.x) of my plug-in WP to Twitter, which does exactly what it says — posts status updates from WordPress to Twitter. This release included a couple of heavily demanded features, including support for custom post types and for tweeting updates on comments.

I’ll admit that there were a couple minor bugs in that release — as a result, I’ve released two updates since then, cleaning up those errors.

Some people, in reading this post, will quibble with the statement that they were minor bugs — and I’m sure that those who were affected by them don’t think so. That’s perfectly fair.

What really bugs me, however, is that if I look at the only real metrics I have for estimating the success of a new feature release, then I’d have to judge that this was a complete and utter failure. Since that release, I’ve had dozens of support requests because of bugs, a handful of small donations adding up to at most $45 (if I include all contributions which weren’t attributable to a specific project), and on the WP to Twitter page at WordPress.org, the “works” gauge has been hovering between split towards broken. And the only working vote was mine.

However, I know that this isn’t really accurate. The reason that I know this is because about a year and a half ago, give or take a few months, I did release a version of the same plug-in that was *really* broken. That was a definite screw-up. At the time, WP to Twitter was a much less popular plug-in, so the impact was dampened, but in the first few hours after release I had several dozen e-mails and support requests informing me of the problem.

In this case, there’ve been 20,000 plus downloads of the updated version with a handful of people (about 10-12) complaining of problems. In my estimation, this is a very small number of issues given the apparent numbers of users.

But I don’t really know that, because I don’t hear very much from those who have a good experience.

This is actually pretty intentional. WP to Twitter is supposed to work quietly in the background — it’s not supposed to be an “in-your-face” plug-in. So when it works, people don’t notice it. However, from my seat today, it seems somewhat demoralizing. It makes me very seriously wonder why I continue to work on WP to Twitter. (For the record, I get a lot more positive feedback on My Calendar, which does help.)

Nonetheless, I have no intention to discontinue support for WP to Twitter. Maybe it’s just an ego trip, but it’s certainly helped me build a thick skin…

Search engines and humans are always looking for relevance. When we first open a document on the web (or in our mail), one of our first actions is frequently to determine whether this document is relevant to our needs. In the case of e-mail or physical mail, this is entirely a “push” experience — messages are sent to us, and we evaluate them for relevance. Spam survives largely on that obscure edge case where we identify their messages as relevant.

When it comes to web documents, the experience is more of an even exchange: we provide search engines with instructions about what we want to find and they send back a response which we both hope will meet our concept of relevance for the given instructions.

Sales and conversions are driven by relevance.

But humans and computers perceive information and relevance in very different ways. This is a challenge for search engines, which need to be tuned to fetch information which appears relevant to a human searcher on the basis of a computer’s understanding of the document. This is also a challenge for people with disabilities — while a person with a disability will generally have the human ability to perceive relevance, their perception of information on the web may be filtered through a computer. For a person who requires the use of a screen reader, this filtering amounts to receiving only the facets of information which are made available both by the author of the document and by the assistive technology they are using.

So, in any online search for information, a person with disabilities is encountering three primary barriers to finding relevant information:

• Did the author consider their needs when the document was created?
• Does their assistive technology offer the resources to transfer that information?
• Did the search engine return information which will be considered relevant to a human?

Everybody encounters the flaws in search engine results. Although searching is far more sophisticated than it was just a few years ago, it is still limited. (And appears to be getting more and more subject to the filter bubble effect — though that’s a different subject.)

Some words have multiple meanings, which are dependent on context. We all use context to guess these meanings: humans use tone of voice, facial gestures, body language, location, environment, and many other factors to assess what the probable meaning of a word may be. Search engines have limited access to this information — some information is mechanically detectable; such as location, and to some degree, environment. They know what words you used to search, and they may know what else you’ve recently searched for. They can use this information to try and better assess your intent and deliver the most relevant information to you.

When it comes down to what information is on a web document, search engines and screen readers have very similar information. As a result, search engines and users of screen readers have similar limitations in their ability to quickly identify relevance on those documents. In some ways, search engines have an advantage, since they can absorb all of the information on the page far more quickly than any human can.

Where a search engine might simply absorb an entire page and move on, humans scan. A visual user will quickly glance over the page, identifying images, headlines, navigation elements, and noticing a few key words along the way down the page. That quick scan of the page can frequently provide all the information the user needs to decide the document deserves another look, or is clearly irrelevant.

Users with disabilities also scan, when it’s an option. This is a place where the capabilities of assistive technology and the attentiveness of a web author really come into play.

For a screen reader user, it’s clear that there won’t be any quick scan of images. Although images may have supporting alt attributes, it wouldn’t be any real savings of effort to check. They can scan through descriptive link text, accessible navigation, and headings, however — if they’ve been provided in a useful fashion. Repetitive link text, headings replaced with images without alt attributes or an inaccessible font replacement method, any of the multitude of inaccessible navigation techniques: they may not prevent the user from getting at your content, but they will absolutely prevent the user from being able to get an overview of the content by scanning.

I mentioned above that search engines have some degree of advantage due to their speed of information absorption. The slower speed with which humans absorb information means that where a search engine might find great relevance caused by repetition of key phrases (or it might not — I would call that keyword stuffing, myself); a human will instead be overwhelmed by the same repetition.

This comes back to context. A human visitor to your web site doesn’t care at all how many times you’ve stated ‘blue widgets’, unless it’s less than once. From our perspective, if you said at the top of the page that you’re selling blue widgets, we understand that everything from that point on is in the context of a blue widget. If you actually say, over and over again, that we’re reading the blue widget specifications, and the pricing on blue widget shipping, and that your blue widget support is superlative — we’re just going to get overwhelmed. It’s unnecessary, and creates the sense of what I’m choosing to call “information blur” (the effect when information is lost due to excessive adjectival description).

What’s my point, again?

Relevance is a prime factor in converting a web visitor into a paying customer. However, humans and computers perceive relevance using very different factors. The best performing web site is going to be created according to the compromise rules which will provide the most relevant information to both humans and to search engines. Visitors with assistive technology, and particularly screen readers, are an interesting test case in this scenario, because the information they receive is filtered in a similar manner to that which a search engine will see.

Creating accessible content: it’s not just the right thing to do.

Something I’ve occasionally found irritating when developing a web site outside of it’s long-term residence (on a temporary URL, in a subdirectory, etc.), is having to choose between either adding relative URLs, the URLs for the current address, or the URLs for the final address for internal links in the development site.

Obviously, using relative URLs will work, but I’m generally reluctant to use them in any CMS (Content Management System), knowing that I may later want to provide access to that content elsewhere on the site. One of the luxuries of a CMS is the ability to use a single source for content which is used in multiple locations, after all — but I don’t much like paying for that with broken links.

However, and especially with a larger web site, it’s not exactly a lot of fun to have to either do a big search and replace or manually run through and replace URLs at the time of launch.

Fortunately, WordPress’ shortcodes API provides an insanely easy way to get around this.

Add this to your theme’s functions.php file:

add_shortcode('url','home_url');

If you’re not comfortable editing your functions.php file, you can also download it as a plug-in.

This very, very short line of code will provide you with the simple inline shortcode [url], which will provide (obviously) the home URL for your WordPress web site.

You can use this in any page or post when you know the URL will be changing like this: <a href="[url]/pretend-page/">.

Even if you’re not planning on moving your web site, it’s clear that typing those five characters is probably a much faster way of getting your home URL than typing it out!