Short answer: To make a WordPress site accessible, choose an accessible theme, use a solid foundation like GeneratePress or Twenty Twenty-Four, add proper alt text, use heading structure correctly, enable keyboard navigation, and test with tools like WAVE or a screen reader. Follow WCAG 2.1 AA guidelines throughout.
Key takeaways
- Start with an accessible parent theme.
- Use heading hierarchy, not just styling.
- Every image needs meaningful alt text.
- Ensure all interactive elements are keyboard accessible.
- Test with automated tools and a screen reader.
- Accessibility is an ongoing process, not a one-time fix.
What you will find here
Accessibility often feels like a mountain of rules and checkpoints. But making your WordPress site accessible doesn’t have to be overwhelming. Think of it as a series of concrete, testable steps. This checklist gives you a practical path to follow, starting from theme choice all the way to ongoing testing. You’ll get straight to the code and decisions that matter.
Choose an Accessible WordPress Theme
Your theme is the foundation. If it’s built with accessibility in mind, half your work is done. Look for themes that advertise accessibility-ready status in the WordPress repository. Twenty Twenty-Four, the current default theme, follows accessibility best practices out of the box. GeneratePress and Astra also have good track records when you pair them with their accessible child themes.
What makes a theme accessible? Proper heading order, keyboard-friendly navigation, good color contrast, and support for skip links. Skip links let keyboard users jump directly to the main content, bypassing repetitive navigation. Check the theme’s documentation or run a quick keyboard test: tab through the homepage and see if you can reach every link and button.
One common mistake is assuming a theme is accessible just because it claims to be. Always verify manually. Open the theme demo and hit Tab repeatedly. Can you see a visible focus indicator on every link? Does the skip link appear when you first tab? If not, the theme might need custom CSS to fix it. You can often add a skip link by inserting a hidden link at the very top of your header template.
Set Up a Logical Heading Structure
Headings are the backbone of screen reader navigation. Users jump from heading to heading to understand your content. Use one H1 for the page title, then H2 for major sections, H3 for subsections, and so on. Never skip levels going from H2 to H4. And don’t use headings just to make text big or bold — that confuses assistive technology.
In the WordPress block editor, use the Heading block and pick the correct level. If you’re building a custom page, verify the order with a heading analyzer. Many accessibility testing tools highlight missing or out-of-order headings automatically.
A practical check: after writing a page, open the HTML and look at the heading tags. They should form a clear outline. If you have an H2 then immediately an H4, there’s a problem. Restructure the content, or add an H3 in between. For blog posts, keep the post title as H1 and use H2 for each main section. Subpoints under an H2 should be H3. This logic should feel natural, like nesting bullet points.
Write Descriptive Alt Text for Images
Every image needs an alt attribute. Decorative images that add no information can have empty alt text (alt=””), but informative images need a clear description. What would you say to someone over the phone to convey the image’s purpose? That’s your alt text.
In WordPress, the Image block has an Alt Text field. The Media Library also lets you set alt text per attachment. Avoid keyword stuffing or phrases like “image of” or “picture of”. Screen readers announce it as an image, so just describe the content directly.
A good rule: if the image contains text, include that text in the alt attribute. For a chart or graph, summarize the key takeaway rather than describing every bar. If you’re unsure, ask yourself: would a blind user miss something important without this description? If yes, write it. If no, use empty alt. For screenshots of code, you can say “Example of a PHP function” and then ensure the surrounding text explains the code.
Ensure Keyboard Navigation Works
Many users navigate with a keyboard instead of a mouse. They tab through links, buttons, and form fields. Every interactive element on your site must be reachable and operable by keyboard alone. Use the native <button> and <a> elements whenever possible because they get keyboard support for free.
If you build custom controls, add tabindex="0" to make them focusable, and handle Enter and Space key presses in your JavaScript. Common pain points on WordPress sites include dropdown menus that open on hover but not on focus, and modal windows that trap focus incorrectly. Test your navigation by tabbing through the entire site without touching the mouse.
For dropdown menus, add aria-expanded to the button that toggles the menu. When the menu is open, aria-expanded="true" tells screen readers the state. Also ensure the dropdown can be closed with the Escape key. With modals, trap focus inside the modal while it’s open — when the user tabs, they should cycle through elements inside the modal, not behind it. Use aria-hidden="true" on the background content to prevent screen readers from reaching it.
Use Sufficient Color Contrast
Text and background colors must have enough contrast to be readable by people with low vision. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular).
You can check contrast ratios with free browser extensions like the WebAIM Contrast Checker or the WAVE tool. If you use a custom color palette in your theme’s customizer, verify each combination. Dark text on a light background usually works best. Avoid light gray text on white — it fails every time.
Don’t forget focus indicators. The outline that appears when you tab to a link must also have sufficient contrast against the background. Many themes remove outlines entirely, which is a huge accessibility problem. If you must override the default outline, use a custom focus style with a high-contrast color and a width of at least 2 pixels. Test with a dark mode plugin or browser setting to ensure contrast holds across themes.
Add ARIA Landmarks and Labels
ARIA attributes help screen readers understand page regions and interactive controls. Use role="navigation" for menus, role="main" for primary content, and role="complementary" for sidebars. Many themes include these already, but check that each landmark has a unique label if you have multiple of the same region (e.g., two navigation menus).
For forms, always associate <label> elements with their inputs. WordPress handles this for built-in forms like comments, but custom forms often miss labels. Use the aria-label attribute on icon-only buttons, like search buttons that show only a magnifying glass. That gives screen readers audible text to announce.
When you add role="navigation", also add an aria-label if there’s more than one navigation region. For example, <nav role="navigation" aria-label="Main menu"> and <nav role="navigation" aria-label="Footer menu"> let users distinguish them. Avoid using aria-label on regions that already have a visible heading — use aria-labelledby instead to reference the heading’s ID.
Make Forms and Error Messages Clear
Forms are common pain points. Every input field must have a visible label. Placeholders are not substitutes; they disappear on input. Use inline validation that announces errors via aria-live regions. WordPress’s comment form is fairly accessible, but plugins like Contact Form 7 or Gravity Forms can vary. Test each form by submitting it empty and see what error messages appear. Are they clear? Do they tell you which field failed?
Error messages should be near the problematic field, not just at the top of the page. Use color, text, and icons together — don’t rely on color alone. And ensure the error message is read by screen readers by using an aria-describedby association.
For real-time validation, use aria-live="polite" on a container that holds error messages. When an error appears, screen readers will announce it without interrupting the user’s current action. Also, consider enabling browser-native validation with required and pattern attributes, but always supplement with your own accessible messages. Test with a screen reader to confirm the error is intuitive.
Test Your Site Thoroughly
Automated testing catches many issues but not all. Start with the WAVE browser extension or the Axe DevTools to scan individual pages. These tools will flag missing alt text, low contrast, and missing form labels right away.
Then test manually with a screen reader. On Windows, use NVDA (free). On Mac, VoiceOver is built in. Navigate through your site using only the keyboard. Listen to how headings are announced. Fill out a form. Can you complete a task without sight or mouse? That’s the real test.
When testing, follow a set of common user flows: sign up for a newsletter, submit a comment, browse products. Note any barriers. Also test with zoom at 200% — content should not overlap or disappear. Use a mobile device to check tap targets are at least 44×44 pixels. Automated tools miss many real-world issues, so manual testing is indispensable.
Maintain Accessibility Over Time
Accessibility isn’t a one-time project. Every theme update, plugin update, or content addition can break something. Add an accessibility check to your deployment pipeline or at least to your regular site maintenance routine. Run a quick automated scan monthly, and do a manual screen reader test quarterly.
Train your content editors on the basics: proper heading levels, descriptive link text (avoid “click here”), and alt text guidelines. A small investment in education prevents many common issues. And remember, accessible sites tend to rank better in search and work better on mobile, too.
Keep a small checklist pinned in your team chat: after each update, test keyboard navigation and run WAVE. Use a changelog to track accessibility fixes. If you use version control, add a disclaimer that pull requests affecting templates or styles must pass an accessibility review. Consistency is key.
Frequently asked questions
What is the easiest way to check if my WordPress theme is accessible?
Look for “accessibility-ready” in the theme tag in the WordPress repository. Then run a quick keyboard test: tab through the homepage and check if you can reach all links, menus, and buttons. Also, use the WAVE browser extension to scan for basic contrast and heading issues.
Do I need to make every image have alt text?
Yes, every tag needs an alt attribute. For decorative images, use empty alt text (alt=””) so screen readers skip them. For informative images, write a concise description that conveys the image’s purpose. Avoid phrases like “image of” because screen readers already announce it as an image.
What are common accessibility mistakes in WordPress forms?
The most common mistakes are missing labels on input fields, placeholder text used as a label, error messages that don’t describe the problem clearly, and error messages that are announced without an aria-live region. Always associate a with each form field and test with a screen reader.
How often should I test my WordPress site for accessibility?
Run an automated scan monthly and a manual screen reader test quarterly. Additionally, test after any major theme update, plugin update, or after adding a significant amount of new content. Regular testing is important because new issues can appear with changes.
Can I make my WordPress site accessible without coding?
To some extent, yes. Choose an accessibility-ready theme and use the block editor’s built-in heading and alt text features. Many accessibility issues can be resolved through content choices. However, custom functionality or poorly coded plugins may still require developer intervention for full accessibility compliance.