WordPress is the world’s most popular content management system (CMS). According to a survey performed by W3Techs, 43% of all websites use some version of Wordpress — that’s about 455 million websites.
But while WordPress offers dozens of accessible themes and extensions, no CMS is perfectly accessible out of the box. Web accessibility requires dedication and awareness. Unfortunately, many creators build their sites without considering the experiences of people with disabilities.
The good news: WordPress gives creators control over virtually every aspect of their content. By testing for accessibility, web developers can build websites that deliver a better experience for all users.
Below, we’ll discuss five of the most common accessibility barriers on WordPress websites (and provide tips for fixing those issues).
1. Poor Color Contrast
Poor color contrast is easy to fix — but about 86% of the internet’s top one million homepages have low contrast text.
When font color isn’t significantly different from background colors, people with color vision deficiency (also called color blindness) and other vision disabilities may have trouble reading it.
The Web Content Accessibility Guidelines (WCAG) addresses this issue with Success Criterion 1.4.3, “Contrast (Minimum).” Per WCAG, text is readable for most users when content meets the following color contrast ratios (the difference in light between the text and the background):
- Normal text should maintain a color contrast minimum of 4.5:1.
- Large text (18 point or larger, or 14 point or larger and bold) should maintain a color contrast minimum of 3:1.
Many WordPress themes ignore these requirements — and even if you’re working with an accessible theme, you may not meet the minimum contrast ratios if you change the color of your text or the background.
The Bureau of Internet Accessibility offers a free Color Contrast Accessibility Validator for testing websites and color-pairs.
2. Missing or Inaccurate Image Alternative Text
Image alternative text (also known as image alt text or simply alt text) provides users with another way to understand the purpose and function of your images.
If a visitor can’t perceive your website visually, they may use a screen reader, which converts text to audio. However, if you don’t provide descriptions for your images, these users will miss out on important content.
WordPress has built-in functionality for adding alternative text to images. Unfortunately, many creators ignore the feature or write long, unhelpful alt text. Make sure you understand the best practices of writing alternative text and get into the habit of writing alt tags for every image.
3. Keyboard Accessibility Issues
In some cases, WordPress can cause serious keyboard accessibility barriers, particularly when the plugin requires user interaction.
For example, a chat plugin might prompt users to send a message to your team. If the chat window isn’t accessible with a keyboard alone, you’re locking out a sizable portion of your audience — and if users cannot close the chat window without using a mouse, they may not be able to read your website.
Media players, forms, and other plugins can also create issues for keyboard-only users. Before publishing changes, check that you can navigate your website using a keyboard. Use the Tab and Shift + Tab commands to move up and down the page. Does everything work as expected?
4. Missing Skip Links
Skip links allow users to bypass blocks of repeated content. If your website has a header menu, screen reader users might not want to listen to the full menu every time they open a new page. Providing a “skip to content" link improves the user experience.
WCAG 2.1 requires skip links, and many WordPress themes provide this feature by default. In many cases, the skip link is hidden until the user presses Tab on their keyboard.
When using skip links, make sure your link is presented visually when it receives keyboard focus. The skip link must change the actual focus, not just the apparent, visual focus. For more guidance, read: What Is a Skip Link and How Does It Work?
5. Missing (or Misused) Semantic Markup
A website’s semantic markup provides programmatically determinable names for different types of elements. Essentially, your semantic HTML explains the structure of each page. When you use subheadings, titles, class and ID names, and other HTML attributes, you ensure that your website will function predictably — regardless of whether visitors use screen readers and other assistive technologies.
When authoring content in WordPress, many designers choose subheadings based on their visual appearance. This can lead to a number of accessibility issues:
- If you use subheadings out of sequential order (for instance, you use an H3 tag before your first H2 tag), some users may believe that they’re missing content.
- If you style text to appear as a subheading, but you don’t actually use a subheading tag, users might miss the content when “scanning" the page for subheadings.
- If you fail to use tags like <header> and <footer>, people may not be able to navigate easily from page to page.
- If you don’t provide accurate title tags, screen reader users might not know whether they’re on the right page until they start reading your content.
You can avoid these issues by using plain old semantic HTML (POSH) to structure your content. After you’ve built a solid structure, use CSS (Cascading Style Sheets) to change the visual appearance as needed.
Of course, if you don’t have experience with CSS, this might seem challenging. Plugins and theme customizers are available to change CSS without coding. Before using these tools, though, focus on your HTML — and test your content carefully after making major changes.
Testing Your WordPress Site for Accessibility
Whether you use WordPress or another CMS, regular accessibility testing is important. Use the latest version of WCAG (currently, WCAG 2.1) to audit your content.
Automated tools can make testing easier. If your goal is WCAG conformance — and compliance with the Americans with Disabilities Act (ADA) and other non-discrimination laws — we strongly recommend combining automated tests with manual tests, performed by people who have disabilities.