Note
This post was written when the Web Toolkit was published on WordPress. All the content from the Web Toolkit is now on digital.govt.nz — published using the Silverstripe content management system.
The Web Content Accessibility Guidelines (WCAG) 2.0 define ways to make web content more accessible to people with disabilities. They form a core component of the New Zealand Government Web Standards 2.0.
This site uses WordPress version 3.4. While the default WordPress theme is fairly accessible out-of-the-box, there are parts of it that need some tweaking in order to improve accessibility. Since we wanted to meet WCAG 2.0 requirements, but also reproduce, more or less, the design of the old webstandards.govt.nz website, we developed our own WordPress theme effectively from scratch.
In this post, I briefly summarise three of the things we did to improve accessibility and/or meet specific WCAG 2.0 guidelines. These are changes you can make whether you start with the default WordPress theme or build your own.
“Skip Links”
WCAG 2.0 Success Criterion 2.4.1 requires us to provide users a way to bypass blocks of content that are repeated across multiple pages. This is especially useful for sighted users who rely on the keyboard and typically navigate by pressing the Tab key to move from link to link. For example, if a keyboard user wanted to move quickly to the main content on a page, without a bypass mechanism they would need to press the Tab key repeatedly to first navigate through all of the menu and other links that come before the main content. This can lead to or exacerbate repetitive strain injuries, as well as pose a significant barrier to people with varying degrees of motor impairment and for whom the keyboard is the main input device.
There are a few ways to provide this bypass mechanism, but one of the most straightforward and conventional is to provide a “skip to main content” link as the first element at the top of the page. This link, when activated, moves focus straight to the main content on the page, allowing a keyboard user to carry on from there and significantly reducing the number of Tab key presses required.
Out-of-the-box, the default WordPress theme does provide “skip links", but these come after two links to the home page followed by the search form, forcing the user to press the Tab key four times on every page to get to the first “skip to primary content” link. This reduces the effectiveness of “skip links". Our implementation makes a “skip to main content” link the very first element on the page. On pages where a secondary menu follows the main content, we’ve added a second “skip link” to enable users to move quickly to that area of the page.
Our implementation also presents the “skip links” link differently depending on the browser, viewport dimensions, and device being used. For most users, where the browser viewport is at least 768px wide, the “skip link” is positioned offscreen, and uses a CSS3 transition effect to emphasise the appearance of the link upon its receiving focus. If you’re using Internet Explorer 8 or above, Firefox, Chrome, or Safari, you can see it in action by putting the cursor in your browser’s address bar, and then pressing the Tab key until you’ve moved into the page content and the “skip link” has become visible. Note that the CSS3 transition effect isn’t supported in IE8 or IE9.
In IE6 and IE7, as well other desktop browsers when the viewport is less than 768px wide, the “skip links” are always visible. Meanwhile, on smartphones, the “skip links” are not provided at all, because the same keyboard-based focus interaction does not exist, screen real estate is at premium, and smartphone users can otherwise use swipe gestures to quickly move to different spots on the page.
“Continue Reading” Links
Ideally, a link’s text should clearly, and on its own, indicate the link’s purpose, that is, where it will take the user. This allows the user to more easily decide whether or not to follow the link. Obviously, links like “Click here” don’t do this, but nor do the “Read more” or “Continue reading” links that normally follow a summary of an article or blog post: “Continue reading what?” In some cases, determining the purpose of these links can be needlessly difficult for some users.
Screen reader users, for example, will regularly call up a list of all the links on a page to help them navigate more quickly. On a page with ten blog post summaries, for example, such a list would include ten “Continue reading” links with no indication of which one goes where. This is how the “Continue reading” links in the default WordPress theme are implemented.
One solution is to add the title of the relevant blog post to the “Continue reading” link. If we have a blog post titled “Government and Social Media,” our “Continue reading” link becomes “Continue reading Government and Social Media". Some will complain, however, that this leads to unnecessarily long and cumbersome links, depending on the length of the blog post’s title. And besides, normally the blog post’s title is already on the page, making it pretty clear to sighted users what article or blog post the “Continue reading” link relates to.
In order to accommodate this concern, one technique is to keep the post’s title as part of the “Continue reading” link, but visually hide the title by positioning it offscreen. The blog post’s title remains part of the link’s text and will be included in the list of links that screen readers provide, but it will not be visible on the page, leaving only the “Continue reading” portion of the link visible. This is how “Continue reading” links have been implemented on this site’s main blog page.
Form Error Messages
When asking users to fill out a form, it’s important to alert them when they’ve made an error and to suggest ways to correct it. These requirements are covered by WCAG 2.0 Success Criteria 3.3.1 Error identification and 3.3.3 Error Suggestion.
By default, WordPress returns some basic, but not exceedingly helpful, error messages if a user forgets to fill the name, email address, or comment fields when submitting a comment on a blog post. To improve on this, we did two things. One was to use some new HTML5 attributes and values for the name, email, and comment fields. This allows more recent and supporting browsers to prevent the form from being submitted if any of the required fields are empty, or if the email or website fields don’t contain properly formatted email or website addresses. The browsers do this on their own, and no additional coding is necessary.
For browsers that don’t support the newer HTML5 attributes and values, we implemented some JavaScript that checks to make sure that required fields have been completed and that the email and website fields contain appropriate content. If there are any errors, the JavaScript returns the user to the form with a clear message about where the errors are and how to fix them, as shown in the image above.
Work Goes On
We continue to make small improvements here and there to the site and its accessibility. If you notice something in particular you think could be better, let us know. If you would like more details about any of the changes we’ve made to address accessibility, please just ask.
