WordPress Accessibility: How to Make Your Site Usable for Everyone

Web accessibility means building websites that people with disabilities can use effectively. This includes people who use screen readers, keyboard-only navigation, voice control, screen magnifiers, or who have color vision limitations. In the WordPress ecosystem, accessibility is both a legal requirement in many jurisdictions and a practical way to reach a wider audience—over 1 billion people worldwide have some form of disability.

In this guide, we cover practical steps to make your WordPress site accessible, following the Web Content Accessibility Guidelines (WCAG) 2.2 at the AA level—the standard most commonly required by accessibility laws including the ADA (US), EAA (EU), and AODA (Canada). For more information, you can refer to the WCAG Guidelines.

Understanding WCAG 2.2 Principles

WCAG is organized around four principles, known as POUR:

Choosing an Accessible Theme

Your WordPress theme's HTML structure and CSS form the foundation of your site's accessibility. When choosing a WordPress theme, evaluate these accessibility factors:

• Semantic HTML: The theme uses proper HTML5 elements (header, nav, main, article, aside, footer) instead of generic divs for everything
• Heading hierarchy: H1 → H2 → H3 follows a logical order without skipping levels
• Skip links: A "Skip to content" link is present as the first focusable element, allowing keyboard users to bypass navigation
• Keyboard navigation: All interactive elements (links, buttons, forms) are reachable and usable with the Tab key
• Focus indicators: Focused elements have a visible outline or highlight (not removed with outline: none)
• Color contrast: Text meets WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text)

Themes tagged "accessibility-ready" on WordPress.org have passed a basic accessibility review. However, this tag indicates a starting point, not full WCAG compliance. Among popular themes, GeneratePress is notably well-coded with clean semantic HTML and proper ARIA landmarks.

Image Accessibility

Alt Text

Every meaningful image needs descriptive alt text. WordPress makes this straightforward—the alt text field is available in the Media Library and when inserting images into content.

Image Optimization for Accessibility

• Do not use images of text—use actual text styled with CSS instead
• Ensure text embedded in images meets contrast requirements
• Provide long descriptions for complex images (charts, diagrams) using an adjacent paragraph or the longdesc attribute
• Ensure images have appropriate dimensions so they do not cause layout shifts (CLS)

Keyboard Navigation

Many users navigate websites entirely with a keyboard—Tab to move forward, Shift+Tab to move backward, Enter to activate links/buttons, Space to toggle checkboxes and click buttons, and Escape to close modals.

Common Keyboard Accessibility Issues

• Focus traps: Modal dialogs that do not allow tabbing back to the main content (modals should trap focus inside the modal, and Escape should close them)
• Missing focus indicators: CSS that removes the default outline on focused elements (never use *:focus { outline: none } globally)
• Non-interactive elements with click handlers: Divs or spans with onClick events that are not keyboard accessible (use buttons or links instead)
• Dropdown menus that only open on hover: Keyboard users cannot trigger hover states. Menus should open on focus/Enter as well
• Custom components without ARIA: Tabs, accordions, and carousels built without proper ARIA roles and keyboard handlers

Color and Contrast

WCAG AA requires these minimum contrast ratios:

Use tools like WebAIM's Contrast Checker or the axe browser extension to verify contrast ratios. Do not rely on color alone to convey information—use text labels, patterns, or icons in addition to color coding.

Forms Accessibility

Forms are one of the most critical areas for accessibility. Whether using Gutenberg blocks, Gravity Forms, or WPForms:

• Label every input: Use the <label> element associated with each input via the for/id attribute. Placeholder text is not a substitute for labels
• Group related fields: Use <fieldset> and <legend> for groups of related inputs (e.g., shipping address fields)
• Provide error messages: When validation fails, identify which field has the error and describe how to fix it. Use aria-describedby to associate error messages with their fields
• Mark required fields: Use the required attribute and visually indicate required fields with text (not just an asterisk)
• Support autocomplete: Add appropriate autocomplete attributes (name, email, tel, address-line1) so browsers can auto-fill form data

Content Accessibility

Heading Structure

Proper heading hierarchy helps screen reader users understand page structure and navigate between sections. Rules:

• One H1 per page (the page/post title)
• H2 for main sections
• H3 for sub-sections within an H2
• Never skip levels (H2 → H4 without H3 is incorrect)
• Do not use headings for visual styling—use CSS classes instead

Link Text

Avoid generic link text that is meaningless out of context:

Tables

Data tables should include:

• <thead> with <th> elements for column headers (with scope="col")
• <th scope="row"> for row headers
• A <caption> element describing the table's purpose
• Simple structure—avoid merged cells when possible, as they are difficult for screen readers to interpret

Testing Your Site's Accessibility

Automated tools catch approximately 30-50% of accessibility issues. Manual testing with a keyboard and screen reader is necessary to identify interaction-based problems that automated tools cannot detect.

WordPress Plugins for Accessibility

• WP Accessibility: Adds skip links, fixes common accessibility issues, adds toolbar for user preferences
• One Click Accessibility: Adds a frontend accessibility toolbar (font size, contrast, links highlight)
• Starter templates with accessibility: Astra and GeneratePress both have strong accessibility foundations in their base themes

Note: Accessibility overlay plugins (that add a floating widget with "fix" buttons) are widely criticized by the accessibility community. They do not make a website accessible—they add a superficial layer that can actually interfere with assistive technology. Focus on building accessibility into your theme and content rather than relying on overlays.

Frequently Asked Questions

Is WordPress accessible out of the box?

WordPress core has improved significantly in accessibility. The admin panel is largely keyboard navigable, and the block editor includes ARIA labels. However, your site's accessibility depends heavily on the theme and plugins you use. A theme with poor HTML structure will undermine WordPress's built-in accessibility features.

Do I legally need an accessible website?

In many jurisdictions, yes. The ADA (US), European Accessibility Act (EU, effective June 2025), AODA (Canada), and similar laws require websites to be accessible. The specific requirements depend on your location, business type, and audience. Consult a legal professional for requirements specific to your situation.

Does accessibility affect SEO?

Yes, there is significant overlap. Proper heading structure, descriptive alt text, semantic HTML, fast page loading, and mobile-friendliness benefit both accessibility and SEO. Sites that follow WCAG guidelines tend to rank better because they provide a fundamentally better user experience. For SEO best practices, see our checklist.

Can page builders create accessible websites?

Elementor and other page builders can create accessible content if used correctly. The key is ensuring proper heading hierarchy, adding alt text to images, using semantic widgets (buttons instead of styled divs), and testing keyboard navigation. The builder itself does not determine accessibility—how you use it does.

What is the most common accessibility mistake on WordPress sites?

Missing or inadequate alt text on images is the most frequently reported WCAG violation. The second most common is insufficient color contrast. Both are straightforward to fix—they require attention and consistent practice rather than technical expertise.

How do I make WooCommerce accessible?

WooCommerce's default templates have reasonable accessibility. Key areas to verify: product image alt text, form labels on checkout fields, keyboard navigability of the cart and checkout process, and accessible error messages for form validation failures. Using an accessible theme as the foundation significantly reduces the WooCommerce-specific work needed.