Accessibility is a hot-button issue in higher ed. In many cases, the Web team is passionate about ensuring equal access for everyone, but no one knows quite how to go about it, and the administration isn’t willing to provide the necessary financial resources to make it a priority.
At that point, the question becomes “What tools and resources can I use to do accessibility for me?”, or, more specifically, “Is WordPress accessible?”
Unfortunately, there is no simple answer to either of those questions. Before we get into all of that, though, let’s take a look at what accessibility standards you need to be paying attention to.
Accessibility Standards in Higher Ed
Regardless of your status, it’s probably best if you start by studying the WCAG 2.0 guidelines. They tend to be broader, more relevant and much more up-to-date than the 508 requirements. Wait a second, did I just say 508 requirements? Who’s required to follow the 508 guidelines? Keep in mind that I am not a lawyer, but my understanding is that any of us working for publicly-funded institutions are required to follow section 508; private institutions (and any institutions outside of the US) are not.
So, if you’re working for a publicly-funded institution inside the US, what should you do?
As I said, I would start with WCAG 2.0. Once you’ve familiarized yourself with those guidelines, then you can take a look at 508 to see where they differ. There aren’t going to be too many places where the two conflict with each other, and those items are usually manageable. WCAG is focused specifically on Web accessibility, while section 508 is focused on technology accessibility altogether (touchscreens in your classrooms, digital signage, computer software, etc.), so it will be easier to digest WCAG than it is to try to pick out the appropriate rules within 508.
Is WordPress Accessible?
The Theme
This is probably the biggest thing to look at. If your theme is accessible, a large portion of your site is going to be accessible (especially in higher ed, where our deep-link pages tend to be tons of plain text, which, by itself, is almost always accessible). If your theme isn’t accessible, then none of your site will be accessible.
If you’re developing a custom theme for your site, you need to build accessibility into it. To begin with, ensure that your theme uses headings properly, and that it doesn’t hide stuff from your users. If you have forms built into your template, ensure that they have proper labels and that you’re not relying solely on visual cues within those forms (or within any area of your site, for that matter). Make sure that your design is created in such a way that there is appropriate contrast between visual elements. Also, code your theme so that the individual HTML elements flow logically. Don’t move things around unnecessarily with CSS, as many assistive technologies will read the site in the order it’s coded, not the order it’s laid out on the screen.
If you want to build ARIA landmark roles into your theme, go ahead and do so. However, don’t build the theme in such a way that those landmark roles need to be there. ARIA is meant to be a progressive enhancement, not a replacement for best practices. If you want a button on your page, don’t code it as a div and give it a landmark role of “button”, make it an actual button and style it appropriately.
You will also want to make certain that your theme properly outputs the language attributes for your site (which language the site is written in, which direction the text flows, etc.) along with any other recommended or required meta tags.
One more area you’ll want to work on is the type of text that’s used for dynamic links. All too often, when most of us develop widgets or content blocks that need to link to other areas of the site, we tend to take the easy route and use generic link text. For instance, probably more than 90% of higher ed websites have links to recent news articles or features on the home page of the site; and an overwhelming majority of those have a link that simply says “Read more” (or something similar) leading to the full text of the article. Unfortunately, when an assistive technology is reading the page, it won’t necessarily connect the visual cues that indicate the headline is related to the “Read more” text; meaning the user will simply hear the words “Link: Read more” over and over again with no context.
Again, when you’re developing the theme, make sure you follow best practices for accessibility while you’re coding it, and you’ll be a long way toward having an accessible website.
If you’re using an out-of-the-box theme, you’ll want to evaluate it to make sure it’s doing things in an accessible manner (you can start by evaluating it for the things I mentioned above).
The Content
The next thing you have to worry about is the content of your site. While WordPress does have specific guides and features in place to assist you in making your content accessible, it doesn’t do it for you. There will be some learning and some training involved in this step.
So, what does WordPress help you do? Whenever you upload an image, WordPress asks you to provide an alt attribute for that image. If you don’t provide one, WordPress outputs an empty alt attribute when it displays the image. This, technically, meets the accessibility requirements; any automated checker is going to see that there is an alt attribute – which is required, whether it’s empty or not – and ask you to review it to determine whether or not the text is appropriate for the image. If you are using the image strictly for illustrative purposes, an empty alt attribute is probably completely appropriate. However, if that image is meant to convey some sort of content or context, the alt attribute should not be empty. WordPress will not automatically analyze the image and try to choose an appropriate alt description (no tool will, as far as I’m aware); instead, you will need to use the tools WordPress makes available in order to provide your own alt attribute.
The visual editor within WordPress also allows you to easily choose heading levels while marking up your content (if you don’t see that selector, you may need to “show the kitchen sink” on the editor toolbar). When you are training your content editors, you need to make sure they understand how that selector works, you will need to make sure they understand how heading levels should cascade, and, as a bonus, you’ll need to make sure they’re not using heading markup strictly to change the way text looks.
The visual editor also offers a few other tools to help you markup your content correctly. For instance, there is a button that allows you to mark something as a blockquote. There are also buttons that allow you to create ordered and unordered lists, so that your content editors don’t have to manually add bullets or numbers to their lists (yes, I still see this type of behavior pretty often, and I’ll bet you do, too).
As with your theme, your content also needs to use descriptive link text. This is an area that will almost certainly require user training. All too often, we see pages littered with links that simply say “click here” (or, even worse, they say “click here”, but only the word “here” is the link). There are multiple things wrong with this behavior. First of all, users aren’t necessarily clicking on anything anymore. They may be tapping, they may be instructing their device to follow links by using voice commands, etc. Secondly, as I mentioned in the section above, assistive technology users will simply here “Link: Click here” or “Link: here” over and over again with no context. Finally, linking just the words “click here” or “here” makes it more difficult, in many cases, for even healthy, able-bodied users to identify and follow the link. Instead, if you link a full phrase, it’s much simpler to identify the link within the content, it’s much easier to follow it, and it’s much, much simpler to identify the context of the link.
On top of training and learning, there are also a number of plugins that can help you move your site toward being accessible. The main one I see talked about is a plugin called WP Accessibility. You can also find a few basic resources on marking up your content accessibly on the WordPress Codex.
Plugins
The next thing you need to look at is the plugins that you’re using on your site. Some don’t do anything to effect accessibility on their own; others do quite a bit. Two plugins I use quite often that need some tweaks in order to be fully accessible are GravityForms and TablePress.
There are two areas in which GravityForms really messes up the accessibility of your content.
First, there are certain types of fields that end up with two separate labels pointing to them. For instance, if you use an “email” field in your GravityForm, and you check the box to enable email confirmation, there will be a label element pointing to the first email input that uses the label text you provide; there will also be a second label attribute pointing to the first email input, positioned as a “description” of the first field (usually says “Enter Email”, with “Confirm Email” being the label element for the second input). If you’re not sure what I’m talking about, you can take a look at the source of the Contact Us form right here on our website.
The other issue with GravityForms is that it applies a tabindex attribute to every element in the form, rather than letting the browser determine the tabindex. While this may sound like a good thing, it’s actually not; it places the form at the top of the tab order, causing all of the other elements in your page to come after the form, no matter how they’re laid out on the screen. Although I haven’t tested it yet, you should, theoretically, be able to short-circuit this by constantly resetting the GFCommon::$tab_index variable to 0.
Another plugin that can be extremely useful, but has minor accessibility issues, is TablePress (formerly developed under the name “WP-Table Reloaded”). That’s a plugin that allows you to easily create rich data tables and insert them into your content. However, TablePress misuses the “caption” element within its tables. Instead of using it to actually caption the table, it uses that as a container for the “Edit” link while you’re logged in. On the plus side, however, it doesn’t output the caption element at all when you’re not logged in and able to edit the table.
Unfortunately, when you set a name and a description for the table, TablePress doesn’t use the caption element or the summary attribute to output those. Instead, it marks up the title of the table as a level 2 heading and marks up the description of the table as a span. However, the good news is that TablePress includes a lot of filters and actions that allow you to modify the markup of the table before it’s output on the page. I haven’t investigated it since WP-Table Reloaded was discontinued and TablePress was picked up, but it looks like you should be able to hook into the tablepress_print_summary_attr filter and the tablepress_print_caption_text filter to modify/set the summary and/or caption for the table.
Administration
This is one area over which you have very little control when using WordPress. The admin area is almost entirely managed by the WordPress core team and the developers of the plugins you’re using. The good news is that the core WordPress admin area is fairly accessible (though it still has a ways to go, and sometimes they make missteps). The other good news is that you can contribute any issues or ideas you have very easily.
Taken altogether, looking at the theme, the content, any active plugins and the administration area, you can see that there is no simple answer to the question “Is WordPress accessible?” It most certainly can be, but the tool won’t do all of the work for you. Now, let’s look at the first question I asked in this article.
What Tools and Resources Can I Use to do Accessibility For Me?
Instead of looking for a magic solution that will do all of your work for you, you should be looking for tools and resources that can help you do your job. There are a number of great tools out there that can perform automated, checklist-style, scanning of your site. These tools are great for uncovering simple issues on your site, and can help you move a long way toward accessibility. For instance, you can use the WAVE toolbar from WebAIM, or you can use any of the other free toolbars out there. You can also purchase a contract with some of the higher-end accessibility companies to provide you with in-depth scanning and analysis (still, though, most of it is going to be automated testing). You can also look at contracting with accessibility experts to help train you and your content editors, and to work with you so you can learn how to make your site accessible.
One of the best things you can do is to start following the #a11y hashtag on Twitter and see all of the things happening there. You can also read the resources available from experts like Derek Featherstone, Karl Groves, Glenda Sims and John F. Croston, III, among others. On top of offering great resources online, all of them speak at conferences regularly, and are generally happy to share their slides. Finally, if you’re not participating in professional development opportunities, you really need to do so. There are accessibility “camps” across the world; there are many great higher ed-focused Web and technology conferences like PSUWeb, HighEdWeb, edUI, etc.; and you can even find books, websites and training opportunities related to accessibility.
Questions? Comments? Complaints?
I hope this article helps to clarify where you should be focusing your accessibility efforts and how you might go about implementing the ideas you have. If you have any specific questions about accessibility in higher ed, especially as it relates to WordPress, please let us know in the comments. We’ll try to answer the questions you have, and might even, hopefully, get a guest blogger in here every once in a while to offer insights we don’t have.