Accessibility for WordPress publishers

Accessibility (or ‘a11y’) doesn’t just refer to people with disabilities but is about ensuring everyone is able to use every site on the web. We work to meet Web Content Accessibility Guidelines (WCAG) 2.0 in all our sites as standard. However, we recently had the pleasure of working with one of our clients who is willing to commit to accessibility habits and pay for third-party testing.

An independent third-party specialist consultancy used both automated accessibility checking software and a manual review using assistive technology/devices to check real-world use and reported back how we could improve the site. It was fantastic to learn new things that we will be taking forward to all our future builds and ensuring we share with our clients.

The benefits to the user of making your site accessible are huge, however it can be a pretty daunting task, especially when you already have a well established website. Here we outline some of the key accessibility rules to follow:

Alt text

One of the biggest issues but extremely simple to fix; using alt text on all your images ensures screen readers [software that enables people with severe visual impairments to use a computer] can provide a text equivalent to images. WordPress helpfully includes a field for users to easily add alt text when uploading images. Alternatively, you can apply alt text directly in the HTML:

<img src ="image-location" alt="image description">

Meaningful link text

If a screen reader user displays a ‘links list’ then some links that are easily understood within the context of a paragraph can become harder to understand. For example, reading a ‘click here’ or ‘read more’ link out of context will mean nothing to the user. Ensure link text isn’t ambiguous and can be understood out of context by describing where the link takes you; e.g: ‘Bob’s study on the advantages of having an office dog’.

Colour contrast

Colour contrast between text and the background can severely affect users’ ability to read information on a page. For text to be readable, it needs to have sufficient contrast with the background. There’s a handy free tool called HTML Code Sniffer to check colour contrast and other a11y issues on your site and WCAG has recommended minimum levels for colour contrast as a baseline guide.

Heading structure

Screen reader users are able to navigate web pages by heading structure. To do this, headings need to be in the correct order on the page; the most important heading has <h1>, the least important heading goes down to <h6>. You should not skip header rankings (so <h1> should always be followed by <h2> and so on). A common mistake is using styles (e.g bold) to create fake headings, instead of using heading styles in content so screen readers are able to read content in the correct order and users can jump between sections easily.

<h1>Main page heading</h1>

<h2>Sub heading </h2>

<h3>Sub-sub heading</h3>

Often, as on this blog post, the title of the page is set to <h1> so editors should not be using <h1> in content as this causes duplicates on the page.

Autoplay media

This is a big sticking point for me and something we often have to discourage clients from using. Although you may be tempted to use auto play media, including carousels, gifs and videos, to add a bit of excitement, it can be extremely detrimental and will often cause users to leave your site. Here’s a few reasons why:

  1. for users with poor vision, autoplaying videos of gifs can be extremely distracting and frustrating when trying to focus on content
  2. for some autistic people, continuous movement can be distressing and if you are unable to stop the movement, you’re likely to leave the site altogether
  3. if there is sound autoplaying, those using screen readers will be unable to use the web page altogether
  4. aside from a11y issues, user research has found that moving media is often mistaken for ads and ignored altogether

Accessible forms

First up, only ask users to enter what is required; if irrelevant or excessive data is requested, users are more likely to give up.

Secondly, make sure all form fields have labels. According to WCAG; “all non-text content that is presented to the user must have a text alternative that serves the equivalent purpose”. Providing descriptive form field labels will make sure users to know what information to enter. You can also use screen-reader only labels that are hidden from sighted users, which we had done for the UK Statistics Authority listing filters.

Accessible tables

When using tables to convey data, it is important to mark-up the tables correctly so screen readers are able to interpret the data: Tables must have column or row heading markup where appropriate. Table headers should be marked with <th> and table data with <td>.  This gives the necessary context to allow screen readers to understand the table. Table contents can be numbers, text, images, and a combination of these but it is important to only use tables for tabular data.

For more information on structuring tables, take a look at the W3 guidance on table concepts.

Many of these are back-end issues but it’s important that content issues like header structure and ambiguous links are instilled in to anyone adding content to the site. With new GDS regulations coming in to affect this year, a11y is more important than ever and should be at the forefront of any website build.