An accessible website works for everyone — people using screen readers, people navigating with a keyboard instead of a mouse, people with colour vision deficiency, and people with cognitive disabilities who need clear, consistent layouts. WordPress accessibility is not just a legal compliance requirement in many jurisdictions; it is good web development practice that also improves SEO, usability, and audience reach. WordPress core has made significant accessibility improvements in recent versions, but theme choices, plugin usage, and content creation habits determine whether a site is genuinely accessible. For the bigger picture, our Complete Guide to WordPress How pulls everything together.
WordPress Accessibility — Core Platform Standards
WordPress itself has a formal WordPress accessibility commitment: all new features in WordPress core must meet WCAG 2.1 AA (Web Content Accessibility Guidelines) standards before they can be merged. The block editor, the site editor, and the admin interface are all tested against these standards. This means the editing experience for content creators has strong accessibility foundations — keyboard navigation works throughout the block editor, ARIA labels are applied to interactive elements, and focus management is handled correctly.
The WordPress Accessibility Team maintains detailed guidelines and regularly audits core features. The WordPress accessibility tag in Trac (WordPress’s bug tracking system) tracks known accessibility issues and their resolution status. When a new WordPress version is released, the release notes include accessibility improvements made in that version. For site owners, this institutional commitment means that staying updated with WordPress core is itself an accessibility improvement — each new version typically fixes accessibility issues identified in the previous version.
Theme WordPress accessibility compliance is where most sites fall short of the platform’s core standards. A site with an accessible WordPress core running an inaccessible theme is still an inaccessible site — the theme’s HTML structure, colour contrast, focus indicators, and ARIA implementation override the core’s standards for all front-end output. The WordPress theme directory has an “Accessibility Ready” tag that themes can apply when they have been reviewed against a specific accessibility checklist covering keyboard navigation, skip links, form labels, contrast ratios, and image alternative text requirements. Filtering the theme directory by “Accessibility Ready” provides a curated list of themes that have passed this baseline review. According to the W3C’s WCAG documentation, WCAG 2.1 AA is the most widely required accessibility standard globally, required by ADA compliance in the US, EN 301 549 in the EU, and equivalent standards in dozens of other jurisdictions.
Making WordPress Content Accessible
WordPress accessibility in content creation is a daily practice rather than a one-time configuration — every image, heading structure, link, and table created through the block editor can either support or undermine accessibility for the site’s visitors.
Images and alternative text: every image added to a WordPress post or page should have descriptive alternative text that conveys the image’s meaning to a screen reader user. In the block editor: click the image → Block settings → Image settings → Alt text field. The alt text — essential for WordPress accessibility — should describe what the image shows, not its filename or generic descriptions like “image” or “photo.” Decorative images that add no meaningful content should have an empty alt text (alt=””) rather than no alt attribute — an empty alt tells screen readers to skip the image entirely, while a missing alt causes screen readers to read the filename. WordPress’s media library allows setting alt text at upload time, which pre-fills the alt text field whenever the image is inserted into content.
Heading hierarchy is a core WordPress accessibility requirement requires that headings use the correct levels sequentially — H1 is the page title (usually set by the theme), H2 is a major section heading, H3 is a subsection of H2, and so on. Screen reader users navigate by headings, jumping between H2 elements to understand the page structure. A page where decorative headings are chosen for visual size rather than semantic meaning (using H4 because it looks right, skipping H2 and H3) produces a confusing heading map that screen reader users cannot navigate meaningfully. The block editor makes heading level selection explicit — the Heading block’s paragraph-level dropdown selects the semantic level, which should match the document hierarchy rather than visual preference. For visual styling of headings at different sizes, use CSS targeting the correct heading levels. Our guide on adding custom CSS to WordPress covers the CSS targeting approach for styling headings without changing their semantic level in the HTML.
Keyboard Navigation and Focus Management
WordPress accessibility for keyboard users requires that every interactive element on the site — links, buttons, form fields, dropdown menus, modal dialogs — is reachable and operable using only the keyboard. Visitors who cannot use a mouse navigate entirely with the Tab key (to move forward between interactive elements), Shift+Tab (to move backward), Enter (to activate buttons and links), and Space (to check checkboxes and activate buttons).
Test keyboard navigation: open the site in a browser → press Tab repeatedly → a visible focus indicator (typically a blue or black outline) should appear around each interactive element in turn, in a logical reading order. If the focus indicator is invisible (removed by CSS) or if interactive elements cannot be reached by tabbing, the site fails keyboard accessibility. The most common WordPress accessibility failure in this area is CSS that removes the focus outline: :focus { outline: none; } is the single most harmful CSS rule for accessibility — it removes all visual feedback for keyboard users navigating the site. Replace it with a styled focus indicator that matches the site’s design: :focus { outline: 2px solid #0073aa; outline-offset: 2px; }. A visible focus indicator does not have to be the browser’s default blue ring — it just needs to be visible, with at least 3:1 contrast ratio against the surrounding background.
Skip navigation links are essential for WordPress accessibility — they allow keyboard users to skip past the navigation menu at the top of every page and jump directly to the main content. Without a skip link, a keyboard user on a site with a 20-item navigation menu must press Tab 20+ times to get past the menu on every page. Add a skip link as the first element in the page body: <a class="skip-link" href="#main-content">Skip to main content</a>. Style it to be visually hidden by default but visible on focus: .skip-link { position: absolute; top: -100%; } .skip-link:focus { top: 0; }. The target element (the main content area) needs a matching id: <main id="main-content">. Most Accessibility Ready WordPress themes include skip links already; themes without them need this addition in the child theme’s header template. Reviews from WebAIM’s accessibility research confirm that missing skip navigation links and invisible focus indicators are the two most common keyboard accessibility failures found in web accessibility audits.
Colour Contrast and Visual Accessibility
Colour contrast is one of the most objectively measurable WordPress accessibility requirements. WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Failing contrast ratios make text difficult or impossible to read for users with low vision or colour vision deficiency — conditions affecting approximately 8% of men and 0.5% of women globally.
Check contrast ratios — a key WordPress accessibility metric: use the WebAIM Contrast Checker (webaim.org/resources/contrastchecker) or browser DevTools’ accessibility panel → input the foreground colour (text) and background colour → the tool shows the ratio and whether it meets AA requirements. Common contrast failures in WordPress themes: light grey text on white backgrounds (a trendy design choice that fails accessibility), coloured links that are only distinguishable from surrounding text by colour (colour-only link differentiation fails for colour-blind users), and placeholder text in form fields that is intentionally light (placeholder text must also meet contrast requirements). Fix contrast failures by darkening text colours or lightening backgrounds in the child theme’s CSS until the ratio meets the 4.5:1 threshold for body text.
Colour-only information fails WordPress accessibility for colour-blind users: a form that shows required fields in red with no other indicator, a chart that uses colour alone to distinguish data series, or error messages that use only a red border without text to indicate an error all exclude colour-blind visitors. Add non-colour indicators alongside colour: required field markers should use an asterisk (*) in addition to a colour indicator; charts should use patterns or labels in addition to colours; error states should include an icon and text description alongside any colour change. These additions make the information accessible to all users while the colour indicator remains as an enhancement for users who can perceive it.
Accessibility Plugins and Auditing Tools
Several plugins assist with WordPress accessibility implementation and auditing without requiring manual inspection of every page.
The WP Accessibility plugin (free, by Joe Dolson, a WordPress core accessibility contributor) adds skip links, language attributes, and keyboard navigation improvements to themes that lack them — fixing the most common accessibility gaps without requiring theme modifications. It also provides options to remove the focus outline suppression that many themes apply and to add landmark roles to theme elements that lack them. For sites using themes that are not Accessibility Ready, WP Accessibility bridges many of the gaps without requiring a theme switch.
Automated WordPress accessibility auditing tools identify known failures without manual testing: the WAVE browser extension (free, from webaim.org) overlays accessibility error icons on the visible page, clicking each icon shows the specific WCAG criterion being violated and the HTML element causing the failure. Deque Systems’ axe DevTools (free browser extension) provides a similar automated audit focused on WCAG 2.1 AA violations. Run these tools on each key page type (homepage, blog post, product page, contact page, checkout page) and fix the errors they identify before addressing warnings. Automated tools catch approximately 30–40% of accessibility issues — the remainder require manual testing including keyboard navigation testing, screen reader testing (NVDA + Firefox on Windows, VoiceOver + Safari on macOS, TalkBack + Chrome on Android), and testing with real users with disabilities when possible. For WordPress accessibility compliance documentation, the axe DevTools Pro version generates formal accessibility reports suitable for legal compliance evidence. Our guide on managing WordPress user roles covers the access control that ensures content editors understand their role in maintaining accessibility — since most accessibility failures in published content originate from editorial decisions rather than technical configuration.
Form accessibility is one of the most commonly neglected areas of WordPress accessibility. Contact forms, subscription forms, WooCommerce checkout fields, and search inputs all require explicit label elements associated with each input field. A placeholder-only form field (where the field label disappears when the user starts typing) is not accessible — the label must remain visible during input. Contact Form 7 generates accessible form markup by default when configured correctly — each field shortcode generates an associated label element. WPForms and Gravity Forms also generate accessible form markup. For custom HTML forms or Elementor form widgets, explicitly add <label for="field-id">Field Name</label> before each input and ensure the for attribute matches the input’s id attribute. Screen readers read the label text when the user focuses the associated input, which is the primary way visually impaired users understand what information a form is requesting.
Video and audio content requires accessible alternatives for WordPress accessibility: captions for videos (text synchronised with the audio content) and transcripts for both video and audio. WordPress’s block editor Video block supports adding captions via a text track file (VTT format). YouTube’s auto-generated captions are a starting point but typically require editing for accuracy — particularly for technical content, non-standard vocabulary, or speakers with strong accents. Audio content like podcasts embedded in WordPress requires a text transcript. Store the transcript either as post content below the audio embed or as a linked downloadable file. Providing captions and transcripts benefits not only deaf and hard-of-hearing users but also users in noisy environments, non-native speakers, and search engines that cannot index audio content directly.
Legal requirements for WordPress accessibility vary by jurisdiction and site type: in the United States, the ADA (Americans with Disabilities Act) has been interpreted by courts to apply to websites, and the DOJ has issued guidance aligning web accessibility requirements with WCAG 2.1 AA. The EU’s European Accessibility Act (EAA) requires WCAG 2.1 AA compliance for many private sector websites and digital services by June 2025. UK equality law similarly requires reasonable adjustments for disabled users. Government and public sector websites face the most explicit requirements, but private businesses — particularly e-commerce sites, financial services, and healthcare providers — face increasing regulatory scrutiny and litigation. Implementing WCAG 2.1 AA compliance through correct WordPress configuration, theme selection, and content creation practices both meets these legal requirements and provides a better experience for the 15% of the global population that lives with some form of disability. If this sounds familiar, WordPress Affiliate Links is worth a look.
