Wheelchair empty infront of concrete stairs.

How best to accommodate accessibility in WordPress themes

Writing accessible content is key for so many reasons beyond the need to help your content reach every member of your audience. Advances in technology have put content in the reach of anyone, no matter their ability. But to enable that, as web developers it’s really important that consideration is made to ensure your projects really give the best experience possible.

Why build with accessibility in mind

Unless you’re like me, you probably don’t browse the web with the inspector panel pretty much permanently open. It’s a habit I can’t seem to get out of but it always makes for some interesting insights when you’re on a poorly coded site or something built with an awful automated page builder. Looking through the source isn’t exciting, but it gives an insight into the way the website was built.

Including necessary markup and tags for content shows an attention to detail that really matters in web development. Any PHP developer will be fully aware of the mayhem a missing ; can cause.

More than ever before it’s important that we consider Search Engine Optimisation for websites. Given that all browsers now have an ‘omni-box’ approach, searching or typing in an URL is the same action and for most people search is the default behaviour even if they know the URL of the site. Including markup intended initially for accessibility purposes helps search engine ranking. Search engine bots that the web and find your site aren’t blessed with ‘eyes’ like we know them.

The obvious use case for accessibility based markup is to help those with impairments that affect their ability to use the site. It’s really important to remember however that every one is an individual, and each disability can affect individual experiences in different ways. There’s no need to focus on how someone with a visual impairment might interact with the website if you forget how someone with difficulties with fine motor control would use a site.

Lastly, and perhaps more on a personal level, I find it far easier to read code that’s got the correct tags in place. Using make debugging and code reviews faster and easier.

The Basics

WordPress offers a fairly good set of tools to help with building your themes with accessibility in mind. But before we dive in, let’s stop and think just what /should/ be included. This is by no means an exhaustive list (the exhaustive list), but these are key messages you should be thinking about your project.

A row of icons as a collage collected from around the web. Icons include a menu-icon, notifications icon, search icon and a close icon.
  • A text based alternative to visual-only elements.
    • This seems obvious for things like images but it’s so easy to forget things like icons, buttons other conventional UI patterns or even just colours and shapes. 
  • A content should follow a structured and relationship focused hierarchy.
    • Basic HTML semantics should be followed, and generally you should use the right tag for the job. <button> is there for a reason!
  • Orientation and Layout
    • This one’s a little harder to write hard rules about, but the layout should allow each section to clearly be followed by the next.
  • Keyboard Accessible
    • Try to avoid elements that are a mouse-only interaction for those who aren’t able to

How WordPress handles accessibility

WordPress is built with accessibility in mind – just look at the markup in the admin interface and it’s clear to see that the developers have included great examples of additional markup in the admin panel to make it accessible. And if you move to the frontend using one of WordPress’ default themes you’ll see examples of the required markup.

In theme development, WordPress provides some tools to help turn the content provided into accessible markup, but the responsibility lies solely with the developer. There are plugins that can add certain features, but they all come with the caveat that only changing the theme can truly affect the accessibility.

One of the most useful markups that can be provided by WordPress is wp_get_attachment_image(). This will output an <img> tag with all the necessary source-sets and alt-tags. This relies on the data being stored in WordPress and it’s super simple to include this information. Convincing clients and content managers to update it however isn’t as easy.

Screenshot showing the facilities that WordPress provide to label and caption images

Outside of images, WordPress until very recently had only one content block provided per-post unless you extended with additional meta boxes and custom fields. Because of this you know that the content that’s output from the_content() is going to be the main content of an article so you can wrap it in a <article> tag to signify that. the_title() can find itself inside a <header> and sidebars and widget-areas are equally separate as <asides>. Navigation menus that are easily wrapped in a <nav> tag. Pretty much all of your footer file can be wrapped up in <footer> and adding role attributes and aria-labels helps by introducing text-based description to visual layouts. Just by using structured tags you are 90% of the way without too much effort. Any additional fields you’ve added you’re going to be aware of where they go and where they fit in the page designs and can tag them appropriately.
The other big area that’s key for accessibility is where content needs to be input. Ensuring that form input fields have appropriate <label> with a for attribute identifying the ID they relate to. Don’t rely on placeholders to indicate what needs to be input. Forms are probably the biggest area where visual indicators are used so care should be made to ensure text descriptions are made available. Red outline of an invalid input box is great for some, but useless if you can’t identify that it’s red, or you don’t have any context to what ‘red’ means.


A lot of the above really helps those who aren’t able to see the site in the same way that others do. The other area that’s equally as important but a lot harder to quantify is visual design. Having information that has clear layouts helps those that are looking at the site instead of having the site read and interpreted by a screen reader or similar technology.

Ensuring colours used offer a suitable contrast is probably the first easy one on a checklist. There’s nothing gained for anyone by having dark-grey text on slightly darker grey backgrounds. Many people are affected by a type of colour-blindness, so it’s worth checking your colour scheme doesn’t have text on backgrounds where the colours aren’t easily distinguishable.
Design also includes the usability of a site and good design is good for everyone, regardless of their ability. More and more devices are touch-screen, so by making buttons and touch-targets a large size will help everyone, and making sure font sizes aren’t too small helps everyone avoid eye strain.

Thinking about menu based navigation and the hierarchy of content is also really important when you have a website with a large depth of information and structure. Using design elements like bread-crumbs which show users their ‘position’ in the navigation tree allow for easy navigation.

Testing and feedback

Above all else, testing your website by using the tools used by others is probably the easiest way of identifying areas that can be improved. Instead of testing with just Chrome and Firefox, add a screenreader to your testing suite. At first it’s difficult if you’ve never used assistive technologies before. I’m sure there are people in your network that are willing to help test your project and provide valuable feedback and insight.

And lastly practice makes perfect – until you start you can’t learn to improve. No website is perfect, but making the effort shows a level of care for all your audience.

A prototype eReader device with a dynamic braille display.

Related Posts

Copyright © Glue Digital Studio Ltd