In the rush to make sure a WordPress blog adheres to the XHTML design standards set out by the Worldwide Web Consortium, a stunning number of theme designers dimly do not adhere to accessibility standards in the interfaces they develop for WordPress users. Their focus is entirely on making the website beautiful and widely compatible with a number of browsers, rather than making it compatible with a wide number of unique and potentially impaired visitors.
This is a huge mistake, and it’s one of the last areas of the web that designers have yet to universally conquer.
Making your WordPress blog accessible to vision-impaired users is exceedingly important, and it’s also relatively easy. It doesn’t require any new XHTML elements or CSS code; instead, it simply requires adding certain things to existing elements and making sure that a site’s structure is composed using certain rules that pertain to the order of tags and the presentation of content.
If you’ve recently completed a WordPress theme, it’s time to double-check it for compatibility with these accessibility rules and ensure that it’s widely usable by every type of internet subscriber.
What is the point of increasing accessibility?
When a vision-impaired user browses the Internet, they typically do so using a special set of tools that reads the content on the screen and separates links into their own page away from the content. Typically, these users can’t see links to click on them, nor see website or entry titles. The screen reader follows the rules of XHTML element order and presentation, along with special meta tags placed within XHTML elements, to read and present content to these users.
Failure to adhere to basic accessibility rules can cause text editors to read irrelevant content, or misinterpret which area of your website contains the entries a vision-impaired reader wishes to peruse. Failure to adequately describe links could lead to confusion that sends an impaired reader away — for good.
Accessibility check, step 1: pay attention to page heading elements
In XHTML code, there is a system of creating headings that numbers them from 1 to 6. This results in tags like “h1″ and “h2″ and so on. Typically, the uneducated WordPress user who is not aware of accessibility standards will actually use the “h1″ tag to surround their post titles. In fact, the old “Kubrick” default theme that shipped with WordPress did this exact same thing, much to the chagrin of impaired readers.
For accessibility purposes, an “h1″ tag should only be used to surround the actual page title itself. It should never be used to indicate a post title, the number of comments, or any entry subheadings. Ever. Screen reader software interprets “h1″ tags as page titles, “h2″ tags as post tiles, and lower-ranked 3-6 headings as subtitles and less meaningful page content.
If your page currently contains a site logo, it’s easy to turn this logo into an accessible H1 tag. Using CSS image replacement, a textual H1 heading can be replaced with an image by essentially using negative margins to blast the text off the screen; the overflow is hidden and the image is placed as a background. To create this effect, surround your page’s title with “h1″ tags:
<h1>My Awesome Blog</h1>
Next, navigate to the theme’s main folder and find the style.css file that applies to the currently selected theme being used in WordPress. Download this file and open it in your text editor of choice. Add two CSS elements to this file:
h1 {
background: transparent url('http://your-domain.com/wp-content/themes/images/your-logo-image.gif') no-repeat scroll 0% 0%;
width: 400px;
height: 80px;
text-indent: -3333px;
border: 0;
}
h1 a {
display: block;
width: 400px;
height: 80px;
text-decoration: none;
border: 0;
}
All that needs to be changed in the above CSS classes is the path to your site’s logo image and the relevant dimensions. While regular users will never notice a difference in your site’s display, those users who employ a screen reader will now know the tile of your blog and it will be read prominently by their software. This is because the text is physically still in the file, but is visually hidden. Screen readers see no visual content, instead preferring to just read content between tags.
Remember, if your blog used “h1″ tags to define entry titles, every single heading tag within your WordPress templates must be “downgraded” by a factor of one. This means titles will now be “h2″ and others will see a one-digit increase as well.
Accessibility check, step 2: are your links meaningful?
All too often, blogs instruct their readers to “click here!” That’s all well and good for the average reader, but those using accessibility software implementations will be vastly underserved by this style of link. Most users will notice that the most popular blogs now use contextual linking that looks something like this:
"I read a <a href="http://huffingtonpost.com">great article at The Huffington Post</a> today."
This link is accessible in theory, because it links to the article in context. It doesn’t implore users to click there, it simply implies that they should. This matters because accessibility software often reads a website and places all of the links contained within the XHTML into a separate part of the software. This link list can then be perused by the impaired user. One quirk of the software, however, is that links are listed according to the text which was linked to in the blog article. Therefore, a blog which links to a site by saying “click me!” will find that its link is displayed using “Click Me” as a title for impaired readers.
A link titled “Click Me” offers no explanation as to what the content is, why it should be clicked, or what it interests the impaired user who is perusing your site with a screen reader. It reduces click through rates and damages a website’s reputation. Also, it frustrates vision-impaired users who simply have no idea what the link is for.
Accessibility check, step 3: are your links titled?
A great way to overcome the “click here” mentality of blog links is to use the title element that can be placed within an < a > tag. This information is actually read to the impaired user by the screen reader software and it can add context to a “click here” link that might be more convenient for the writer’s purposes when pandering to those users will full vision. It looks like this:
'I read a <a title="GOP nomination 2012 article" href="http://huffingtonpost.com">great article at The Huffington Post</a> today.'
Now the reader knows not only that the article was great, but also what the article was about. It will be read to the user by their software as “GOP nomination 2012 article, great article at the Huffington Post.” It isn’t the most elegant use of conventional English semantics, but it gets the job done and doesn’t leave them guessing about the link’s content or purpose.
Accessibility check, step 4: catering to the color blind readers
Remember how every link on the internet used to be colored blue and paired with an underline? It was a relatively simple way of universally indicating that this was going to take users to a new page either within the site or at a new webpage entirely. Then CSS came along and links got over-styled to the point where they no longer looked like links. Designers removed the underline, or made it a dotted line, or made the link italicized, and all hope of standardization went out the W3C window.
In most senses, this was a great thing. Blue links don’t match orange websites, and users should be able to change their appearance. They should, however, change them within reason — and that means keeping the legendary underline as part of the appearance of website links.
Color blind users, in some case, simply cannot tell one color of text from another. It might all appear black, or it might all appear white. Without a clear indication that a link has been included in a block of text, there is not only no incentive for them to click on the link, there is also no reason for them to even hover their cursor in the general vicinity of this hyperlink. Keep the underline, which can be done one of two ways in a CSS document.
First:
text-decoration:underline;
Second:
display:block; border-bottom:1px solid #000;
If the link is displayed as a block element, then it will require the second method. Otherwise, do your colorblind readers a favor and simply indicate that the text be underlined when it’s part of a link. They’ll thank you and your referral rates will jump — both really great things for the average blogger.
Accessibility check, step 5: focus on forms
WordPress makes extensive use of forms, especially on single-entry pages that encourage user commenting. Those users who are vision impaired should be able to join in the conversation as well as their sight-enabled fellow readers, and this can be done as long as a website follows a few simple rules when adding these forms to WordPress pages:
1. Every form absolutely must have an “ID” associated with it. This is often done by default when WordPress generates its own comment form, so rest assured that your site is likely at least following this rule.
2. Keep it simple and don’t ask for useless information that most customers don’t have, don’t want to give, or might get confused when asked for.
3. If a form is required, and is labeled as such, it should be within the “label” tag of the actual text area or text box element. Do not place this outside of the form, as this will cause screen readers to just totally ignore the text. That’s not helpful for users who are vision impaired.
4. Employ jQuery on your WordPress website to enable ongoing form validation. This process ensures that users will not be confusingly returned to the comment page after submitting their comment to your site simply because they forgot their email address or something similar. Form validation displays any errors as part of the text area’s “label” tag, meaning it’s already accessible to screen reader users who are likely to benefit most from form validation.
Accessibility check, step 6: validation is still important, so make sure it’s happening
Form validation might be important to vision-impaired commenters, but entire site validation should be important to developers and their impaired users alike. Because screen readers only see code, and therefore only share your website’s content that is deemed important and usable, XHTML validation is more important than ever.
Screen reader software pays close attention to thinks like <p> tags and <div> tags, as well as image “alternate” text in the “alt” tag and title, caption, and label elements without your website’s XHTML code. The unseasoned designer might think that these tags are only important for the site’s visual appearance, but more advanced designers know that they directly impact which content a vision impaired user hears and which content might be left behind — for better or for worse.
WordPress largely accessible without user intervention
The default WordPress themes, like TwentyTen and TwentyEleven, are largely compatible with accessibility standards that cater to the color blind and vision impaired. These themes can probably be left alone.
But for those users who have designed their own themes, or are using someone else’s custom-designed template, ensuring proper compatibility with screen readers will make those with vision impairments more likely to click links, read articles, and keep coming back for quality content that is well-constructed and able to be read to them without complications or distracting glitches.
Vladislav Davidzon is the principal of a US-based online marketing consultancy, developing integrative solutions through high impact search engine optimized WordPress websites for socially responsible customers of all sizes around the world. For more details visit Vladislav Davidzon & Associates.
Is your website accessible to vision-impaired users? What have you done to make it easier on them?
| Font bundle: 5 Gorgeous Fonts from Gerren Lamson – only $15! |  |