WordPress Accessibility: A Guide to Making WordPress Websites Accessible

WordPress accessibility means building and publishing WordPress sites that people with disabilities can use. This guide explains standards, common problems, testing methods, and a practical remediation workflow you can follow today.

What is WordPress accessibility and why it matters

Accessibility ensures people with visual, hearing, motor, or cognitive impairments can perceive, understand, navigate and interact with your site. Accessible sites reach more users, reduce legal risk, and improve SEO and usability for everyone.

Standards and terms to know

Target the WCAG success criteria used by many organisations. WCAG 2.1 at AA level is the common baseline for public-facing sites. Learn these terms:

• WCAG — Web Content Accessibility Guidelines, versions 2.0, 2.1, 2.2 and beyond
• WAI-ARIA — roles and attributes that expose semantics to assistive technology
• Keyboard focus — visible focus and logical tab order
• Alt text — descriptive text for images

How WordPress affects accessibility

WordPress is a content management system. Accessibility depends on three areas: the theme, plugins and the content editors. Each layer can add or remove accessibility barriers.

Themes

Choose an accessibility-ready theme from the official directory. Themes control heading order, semantic HTML, focus styles and landmark elements. If a theme lacks proper landmarks or uses visual-only headings, fixing content alone will not be enough.

Editor and blocks

Gutenberg and block plugins add structure. Use core blocks that output semantic HTML. Check third-party blocks for aria misuse and broken keyboard interaction before using them site-wide.

Plugins

Plugins can alter markup and add widgets. Some accessibility plugins help but they do not retrofix every problem. Audit plugin output where it alters forms, navigation, or dynamic content.

Common accessibility issues on WordPress sites

• Missing or meaningless image alt text
• Improper heading levels, skipped or used only for visual style
• Poor colour contrast that fails WCAG ratios
• No visible keyboard focus or custom focus removed by CSS
• Forms without label associations or unclear error messages
• Dynamic content not announced to assistive tech
• Complex navigation without skip links or landmarks

Testing: automated checks and human tests

Combine tools with manual checks. Automated tools find many problems but they miss semantics and real user interaction problems.

Automated tools to run

• Chrome Lighthouse for broad audits
• Axe or axe DevTools for rule-level results
• WAVE for per-page visual reports

Manual tests to perform

• Keyboard test: tab through the page, open menus, submit forms, and confirm focus is visible and logical
• Screen reader test: try NVDA on Windows or VoiceOver on macOS, listen for page structure and announcements
• Contrast check: verify a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text
• Mobile and zoom: test at 200% zoom and on small screens for responsive behaviour

Step-by-step remediation workflow (practical)

Follow this ordered workflow. It limits rework and targets the highest impact fixes first.

1. Run a site-wide automated scan to list pages with failures
2. Prioritise pages by traffic and business impact
3. Fix template-level issues in the theme: headings, landmarks, focus styles
4. Address reusable blocks and forms in plugins or theme templates
5. Train content authors on alt text, headings and link wording
6. Re-run automated scans, then perform keyboard and screen reader checks on priority pages
7. Publish an accessibility statement and a way for users to report issues

Decision framework: theme, plugin or custom code

Decide where to fix problems based on scope and sustainability.

• If the issue appears on most pages, fix it in the theme templates
• If a plugin adds the markup, update or replace the plugin
• If only a few pages need patching, use block templates or lightweight filters

This approach keeps custom code minimal and easier to maintain when WordPress updates.

Practical fixes for frequent issues

Skip links and landmarks

Add a skip-to-content link at the top of the page that becomes visible on focus. Use semantic landmarks such as nav and main in templates.

Alt text and decorative images

Provide meaningful alt text for informative images. Mark purely decorative images with empty alt attributes so screen readers skip them.

Headings and document structure

Use headings as structure, not style. Start with a single top-level heading per page and then use nested levels without skipping.

Forms

Attach label elements to inputs. Provide clear inline errors, and use aria-describedby for help text when needed.

Keyboard focus

Ensure interactive elements receive keyboard focus. Avoid removing focus outlines unless replaced with a visible custom style.

Captions and transcripts

Provide captions for video and transcripts for audio to meet WCAG success criteria for media.

Checklist for content editors

• Write descriptive link text that explains destination or action
• Use headings to reflect document structure, not font size tools
• Fill the image alt field with a concise description or leave empty for decoration
• Provide captions for media and text alternatives for complex images
• Keep form labels visible and avoid placeholder-only labels

Checklist for developers and theme authors

• Use semantic HTML and ARIA only to fill accessibility gaps
• Respect native controls instead of re-implementing them
• Test keyboard navigation and focus order in templates and widgets
• Keep CSS that affects focus visible and consistent across browsers
• Run automated tests as part of your deployment pipeline

Legal, policy and publishing advice

In the UK, public sector websites must follow accessibility regulations such as the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. For any site, publish a clear accessibility statement that lists known issues, conformance level and contact details for reporting problems.

Monitoring and continuous improvement

Accessibility is not a one-time task. Schedule regular automated scans, include manual checks in release testing, and collect user feedback. Track fixes and keep an accessible design system or pattern library for reuse.

Follow the workflow above, fix template issues first, and train authors. Small, consistent steps reduce technical debt and create a site that works for more people.