Accessites.org
WordPress and Accessibility

Many sites are built using WordPress (WP) as the content management system (CMS). Not just blogs but full-blown ecommerce sites and others. The power and flexibility of WP is evident by these implementations. And speaking of implementations, it was used as the CMS for a site recently built as a Web Content Accessibility Guidelines (WCAG) 2.0 implementation, to the level of AAA (one of two in the world with the other being Vision Australia). To learn more about that, here’s a short summary of the experience. This article is about WordPress’s end of things.

Out of the Box

After downloading and installing WordPress one will note that it’s pretty solid, semantic, and accessible, even with the default theme. However, it’s not perfect, and that’s what this article will focus on. It’s not a critique of the default theme, or any theme for that matter. Instead we will focus on two specific points of concern that run deeper. But before these points are addressed, it should be noted that most of WP’s accessibility does rely on the quality of its themes, plugins, and widgets. In other words, to the careless or ignorant, it’s quite easy to destroy the integral quality of WP via the simple act of making it one’s own.

In this article we will assume you’re access savvy. We will also assume that if you use WP you’ll select and implement a quality theme, plugins, and widgets, and in such a way that the system’s inherent quality isn’t compromised. If you don’t know where to begin, this WordPress theme might help (the one this site is built on). It’s not perfect and it is in need of an update, but compared to many available offerings, it’s a good start (as exemplified by the Access Matters, Paciello Group, Permanent Tangent, JB Visions, and other accessiblistas who have used it). Moreover, it comes with some popular plugins that have been made more accessible.

Easily 99% of WordPress’s accessibility and semantics can be influenced by rather simple theme, plugin, and widget modifications. And since we’re assuming you’re access savvy as stated above, let’s just say you’re all set in that regard. We won’t discuss the myriad user-level things one can do to accommodate people’s needs, nor will we bother discussing what can go wrong (this isn’t a book). We’ll leave that to you and instead focus on two integrated issues that aren’t easy to deal with or are even impossible to address without going into the system’s core files — which isn’t recommended! If these items concern you, dealing with them can be frustrating.

Core Issues

Using WP as a CMS for a basic communication web site, using a perfected theme and add-ons, one can get extremely close to a AAA accessibility rating under the guidance of the WCAG 2.0. That is pretty impressive and a hearty pat on the back goes to the WordPress team. Seriously.

But…

Empty Search

WP’s comment errors such as submitting an empty response are less than elegant. The user is sent to the script file and given a basic text error. That could be and should be done better, but it is basically accessible. Empty search errors, however, are another matter altogether. Search inputs send to PHP_SELF, instead of REQUEST_URI, and on a system like WP, that points to the index page. If the user submits an empty search, instead of being notified, they are whisked away to the site’s index. At LF Legal this one item failed Success Criteria 3.3.1 and 3.3.3:

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A) — Guideline 3.3 Input Assistance

3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA) — Guideline 3.3 Input Assistance

As you can see, the first issue defined prevented LF Legal from reaching an A-level rating, at least on the search page. Due to the way the WCAG 2.0 applies, this wouldn’t fail the whole site, even though search is a whole site function.

Jump to the Empty Search Solution.

Entry Pagination Problem

When using the built-in pagination feature provided by WordPress, links are placed at the bottom of the content. To be clear, this shouldn’t be confused with multipage archiving links, like “Older Entries,” this feature applies to individual posts and pages. The pages are broken by placing the <!--nextpage--> tag where the break is wanted.

Under some conditions, if you want to make individual pages navigable by number instead of just offering a “Next Page” link, for example, and if you are making the post or page more than two pages, an accessibility issue can occur. Specifically a lack of link separation. I cannot point to it within the WCAG 2.0, it’s no longer required. But I feel it should be. A lack of link separation to the users who browse sans-styles, without images, or via a text browser like Lynx, makes for a less than suitable condition. It doesn’t need to be that way.

Jump to the Entry Pagination Solution.

What to Do…

The best thing you can do is encourage the folks at WordPress to handle these issues with the next upgrade. If they do it, then you don’t have to worry about it. But it doesn’t mean we’re without solutions.

Empty Search Solution

This is not a high tech solution — that needs to come from the folks at WordPress — but this is a solution all the same. Simply add the whitespace character   to the input value and that’s it. If a user tries to search for nothing, then they will be given their results for their search for “ ” and, in most themes, a chance to continue searching. Ideally one should get a negative but informed result, such as:

Error: You need to enter a search word in the search field.

The whitespace fix, while certainly far from elegant, was accepted by the powers that be, but it could be and should be done better.

Jump back to the Empty Search Problem.

Entry Pagination Solution

Under the conditions described, the only fix that we’re aware of is to use the ePage Links plugin authored by Rich Pedley, created specifically to correct this problem.

Jump back to the Entry Pagination Problem.

Maybe a Fix is Due?

Please bear in mind that some versions may be different and there may be more applicable concerns with older versions. That’s for you to investigate. If not addressed already, these items should be. The ball, as they say, is in WP’s court. In any case, a huge pat on the back still goes to those folks for making such a system that allows this level of accessibility retention. As far as we know that in itself is a rarity — much of what’s out there doesn’t even validate.

Again, a AAA WCAG 2.0 site was made with WordPress. This says a awful lot for WP and how good it is as a platform. Changes needed to be made, but almost everything was done on the theme level as it should be.

Filed under Our Articles — Subscribe, Trackback,

Bookmarking Links » del.icio.us | Digg | blogmarks | Ma.gnolia | StumbleUpon | Technorati | Help |

These posts may be related:

Pacifica Training »

A New Tool, A New Look, A New Method »

Making a Font Selector »