The Ultimate Guide to Accessibility and WordPress

The Ultimate Guide to Accessibility and WordPress

So you want to make an accessible WordPress website? Congratulations – your site will be available to the widest possible audience!

Not sure why accessibility is valuable? Accessible sites have benefits including faster load speed, better SEO and being good for PR. Plus making an accessible site is just the right thing to do.

Themes tagged accessibility ready on WordPress.org have not only fulfilled the usual theme review guidelines but passed additional accessibility checks.

The checks are modeled on the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) level AA.

A good starting point if you are building your own theme is the Underscores starter theme, Underscores follows web standards and has a number of accessibility features built-in.

So what features should a good accessibility ready theme have?

Appropriate Alt Text for Images

Why? Screen reader users need alt text to get the meaning of images included in content.

Any inline images included in the theme should have alt text.

That includes featured images. However, even if the code is present to show the alt attribute, it still relies on the user inputting the correct text.

Decorative images like background images should be added via CSS. Background images do not have an alt attribute.

Alt Text: Yes

In Twenty Seventeen theme, the header image alt text matches the site title.

Featured image alt text is whatever the user has inputted.

Twenty Seventeen theme’s implementation of alt text.
Twenty Seventeen theme’s implementation of alt text.

If there’s no alt text present, the alt text defaults to alt =“”. This is actually quite sensible, because a blank alt attribute is better than irrelevant alt text.

Keyboard Accessible Links and Menus – Particularly Drop-Down Menus

Why? Some users with mobility impairments can’t use a mouse. They are reliant on the keyboard (or keyboard-like devices) to navigate the interactive features of a page. The Tab key is used to move forward through elements., and Shift+Tab to go back.

You should be able to access the following by tabbing through the page:

  • Links
  • Menus
  • Buttons
  • Form fields

Often with menus, the top-level menu items will be keyboard accessible but dropdown submenus will not!

Example: Accessible Drop-Down Menus

Gently theme implements dropdown menus in an accessible way, as they can be reached by keyboard as well as mouse.

Gently theme has a keyboard accessible dropdown menu showing keyboard focus.
Gently theme has a keyboard accessible dropdown menu showing keyboard focus.

If creating your own theme, Underscores has keyboard accessible drop-down menus built-in, or you can try this tutorial: Creating Accessible Drop-Down Menus.

Visible Focus Styles

Why? Keyboard users need something visual to show them where they are on the page when tabbing through. If there’s no focus style, it’s hard for them to tell what they are interacting with.

Try using the keyboard to tab through the next web page you visit.

Can you tell which link is which?

Themes often reset the default focus style. You will often see this in style.css files:

Unfortunately, this code reduces accessibility, and developers often don’t think to set their own focus style.

The focus style may include a color background – but it must also meet color contrast guidelines.

Visible Focus Styles: Yes

The Penguin theme implements focus styles in different ways, but it’s easy to tell which link is the current one.

Penguin accessibility ready theme showing white on blue postmeta keyboard focus style.
Penguin accessibility ready theme showing white on blue postmeta keyboard focus style.
Penguin accessibility ready theme with link keyboard focus style showing an outline.
Penguin accessibility ready theme with link keyboard focus style showing an outline.

Sufficient Color Contrast

Why? People with a vision impairment may struggle to read text on a low contrast background. Even reading on a laptop in bright sunlight can prove tricky for someone without sight problems.

The recommendation is the same as that in WCAG 2.0 level AA – a contrast ratio of 4.5:1 for normal text.Colour contrast: No

Colour Contrast: No

The WAVE WebAIM tool reveals that ZBlackbeard theme has many areas of low color contrast.

ZBlackbeard theme colour contrast errors highlighted in red by WebAIM’s WAVE tool.
ZBlackbeard theme colour contrast errors highlighted in red by WebAIM’s WAVE tool.

Native HTML for Buttons and Links (Or Equivalent Markup to Behave As Native Controls Do)

Why? Incorrect markup will disable your users from using custom controls. For example, a user might not be able to tab to or press a custom button.

If you want to make a button behave like a button, it’s simplest to use the <button> element! It’s understood by all assistive technologies.

Just use button!

Skip Links

Why? Skip links save screen reader users or keyboard users from having to pore through long lists of links repeatedly.

Skip links can be made invisible to sighted users through CSS. They will only be visible if the user tabs through the page, or if a screen reader is used.Skip links: Yes

Skip links: Yes

Twenty Sixteen uses a “Skip to content” link, which allows the user to bypass the navigation and go straight to the page content.

Twenty Sixteen uses a “Skip to content” link which allows the user to bypass the navigation and go straight to the page content.

Twenty Sixteen theme showing a Skip to Content link.
Twenty Sixteen theme showing a Skip to Content link.

Some accessibility ready themes have a skip to sidebar link as well.

Semantic HTML Headings

Why? Good heading structure benefits everyone. Sighted users can easily scan down the page to see what’s important. Screen reader users can navigate by heading level to the section they want.

Headings: Yes

Twenty Seventeen marks up headings in a logical order, as seen using VoiceOver.

Twenty Seventeen theme. The Headings menu in VoiceOver shows a semantic heading order.

Headings: No

Viewing the same content on another theme shows a less accessible implementation.

There are two H1 headings and there is a missing heading level between H1 Hello world! and H3 One thought on “Hello world.” A blind person might wonder where the Heading 2 went!

VoiceOver Headings menu in Ffashion theme showing a duplicate Heading 1 and missing Heading 2.
VoiceOver Headings menu in Ffashion theme showing a duplicate Heading 1 and missing Heading 2.

Screen Reader Text for “Read More” Links

Why? Screen reader users looking at links out of context e.g. on a Blog page with excerpts may encounter many “Read more” links. Without screen reader text, the link destinations won’t be obvious.

Screen reader text is also valuable for icon fonts, which can’t have alt text.

Screen Reader Text: No

Illdy theme has lots of “Read more” links. A user tabbing quickly through the links will hear only “Read more” and won’t know which post each link goes to.

The Illdy theme Read more links don’t reveal the post title when tabbed through.
The Illdy theme Read more links don’t reveal the post title when tabbed through.

Screen Reader Text: Yes

The Splinter theme implements screen reader text for its Font Awesome social icons. The screen reader text for the Facebook icon reads “Go to Facebook”.

Splinter accessibility-ready theme shows screen reader text for Font Awesome icons.
Splinter accessibility-ready theme shows screen reader text for Font Awesome icons.

For detail on implementing this technique and the CSS required, read Hiding text for screen readers with WordPress Core.

No Autoplaying Media e.g. Carousels

Why? Autoplaying media is bad for those with cognitive impairments – it can prove confusing or distressing if the user can’t control it. If the media includes audio, screen reader users are also affected. It can interfere with the reading of the page.

It’s preferable to include media elements in plugins.

Themes are for presentation and plugins are for functionality.

Explicit Form Labels

Why? Forms without clear labelling can be problematic for screen reader users. They may not be able to tell what information is required in each field.

Placeholder text inside a form field is not enough!

Form labels: Yes

The Milky Way theme labels the form text fields and textarea so there is no doubt about what they do. The fields that are required are clear.

The comment form for Milky Way theme with clear form field labels.
The comment form for Milky Way theme with clear form field labels.

Form Labels: No

In the Inspirez theme, a VoiceOver user can hear a description of the comment form fields if they open the Rotor to the Form Controls menu.

However, using the Tab key to access the fields does not reveal their purpose. Also, as soon as the field is chosen, the placeholder text disappears.

The Inspirez theme comment form name field. VoiceOver reads ‘required, edit text with autofill menu.
The Inspirez theme comment form name field. VoiceOver reads ‘required, edit text with autofill menu.

The user might well think:

What do I fill in here? Name or Email?

And subsequently type the wrong thing, with the frustration that entails.

ARIA Landmark Roles

Why? As with headings, ARIA landmark roles help screen reader users navigate to particular parts of the page.

Roles to use are:

  • banner
  • main
  • complementary
  • contentinfo
  • search
  • navigation

ARIA Roles: Yes

The Some theme implements ARIA roles throughout the page structure. VoiceOver users can switch to the different areas marked with roles.

The main role corresponds to the main content area.

VoiceOver ARIA Landmarks menu for some theme, showing the main role.
VoiceOver ARIA Landmarks menu for some theme, showing the main role.

Clear Typography

Why? Fancy fonts can look cool but make your site harder to read for all users. Nielsen Norman Group specifies that content legibility is a key indicator of usability.

This is not a requirement for an accessibility ready theme, but is recommended.

Guidance:

  • Use at least 16px font size for body text.
  • Go for serif or sans serif fonts, not cursive or fantasy types.
  • Avoid large swathes of text in uppercase.

Typography: No

The Germaine theme uses the Great Vibes font for headings. It’s pretty, but this script font is less legible than a serif or sans-serif font.

Germaine theme with post headings in Great Vibes font.
Germaine theme with post headings in Great Vibes font.

Things That Should NOT be in an Accessibility Ready Theme

Links That Open in New Windows/Tabs Without Warning

Why? Some users will be confused if links open unexpectedly in a new window or tab, because they can’t use the Back button to return to where they were.

Watch for target="_blank" in links.

It’s best to avoid opening links in new windows altogether, but if you must, provide a warning.

The simplest and best way to do this is through text. Add (opens in new window) after the link text.

Links: No

The Dream Spa theme has a button in the Customizer to add slides to a slider. This opens in a new window, but there’s nothing to let the user know beforehand.

Dream Spa theme Customizer; a button link opens in a new window.
Dream Spa theme Customizer; a button link opens in a new window.

Links: Yes

Tiny Framework uses a combination of the Font Awesome external link icon and screen reader text to indicate that a link opens in a new window.

Tiny Framework external link icon with screen reader text to indicate the link opens in a new window.
Tiny Framework external link icon with screen reader text to indicate the link opens in a new window.

Positive Tabindex Values

Why? Tabindex values of 1 or above mess up the natural tab order, and confound keyboard-only users’ expectations.

Adrian Roselli shows why you shouldn’t do this in his article: Don’t Use Tabindex Greater than 0.

Accesskeys

Why? Accesskeys are a good idea in principle, but are inconsistently implemented across websites. There is also the problem of assistive technology using some of the same keyboard shortcuts.

Useful Resources and Accessibility Testing Tools

Resources:

Tools:

Conclusion

An accessibility ready theme lays a strong foundation for an accessible site but doesn’t guarantee accessibility of the finished product.

Why?

Accessibility depends on the content added to a website. Most of this is determined by the user, not the theme author. Testing against a formal accessible standard such as WCAG 2.0 AA can only be done when the website is finished.

You could build a beautifully accessible building and ruin it by choosing to furnish it poorly.

For example:

  • Illegible signage
  • Loose rugs
  • Uncomfortable furniture
  • Inadequate spacing between desks

Similarly, you could spoil your best efforts at making a website accessible by choosing to add inaccessible content.

For example:

  • Not adding headings to articles
  • Adding “click here” links
  • Using jargon in sentences
  • Adding autoplaying videos with no controls

So it’s important to know how to create content in an accessible way too, and to train the people updating the website.

Understand that implementing accessibility is an ongoing process, best started early – and you will be on the right path to deliver a truly inclusive website.

Claire Brotherton
Have you used an accessibility ready theme as the basis for a client project? What did you learn? Let us know in the comments below.