Accessibility isn’t an optional add-on. For small businesses, it’s a practical way to reach more customers, reduce legal risk, and make your site easier for everyone to use. This checklist focuses on the most common accessibility gaps on WordPress sites and gives clear steps you can apply now—no full redesign required.
How to use this checklist
Work top to bottom: start with simple content and theme fixes, then move to interactive elements and technical checks. For each item I note whether it’s something a site owner can do alone, or when you should hand it to a developer. If you need help implementing any step, my web development page has service details and contact options: Web Development.
Essentials: content and structure (quick wins)
- Headings: use semantic headings in order. Verify pages use one <h1> followed by <h2>–<h3> logically. Fix by editing the block or theme template. (Site owner)
- Alt text for images. Add meaningful alt text describing function or content. Decorative images should have empty alt attributes (alt=”). Use the Media Library or block settings. (Site owner)
- Descriptive link text. Replace “click here” or “read more” with context-rich phrases like “view our pricing” so screen reader users know the link target. (Site owner)
- Readable font sizes and contrast. Ensure body text is at least 16px and color contrast meets AA (4.5:1 for normal text). Use a contrast checker and adjust CSS if needed. (Site owner / developer)
Forms and navigation (high impact)
- Label every form control. Inputs must have visible labels or ARIA-label attributes. Use label elements linked with the input’s id. Test by tabbing through the form. (Site owner / developer)
- Keyboard focus visibility. Ensure focused controls show a clear outline. If your theme removes outlines, restore them in CSS (outline: 3px solid #… or box-shadow). (Developer)
- Logical tab order. Test navigation with the keyboard (Tab/Shift+Tab). If order feels wrong, review the DOM order and stop relying on tabindex hacks. (Developer)
- Accessible error messages. Associate inline error text with inputs (aria-describedby) and ensure messages are announced to screen readers. (Developer)
Media, color, and visual content
- Captions and transcripts for video/audio. Add captions or provide a transcript for any informational media. Use hosted solutions or WordPress plugins that support caption files (VTT). (Site owner / developer)
- Avoid color-only cues. Don’t rely on color alone to convey meaning (e.g., “red indicates required”). Add icons or text labels as well. (Site owner)
- Responsive images with captions. Use the responsive image markup WordPress generates and add captions when helpful for context. Screen reader users rely on alt and captions for non-decorative visuals. (Site owner)
Widgets, menus, and dynamic content
- ARIA roles for custom widgets. If your theme or plugin inserts custom controls (tabs, accordions), ensure ARIA attributes are present and states (expanded/collapsed) update. Check with a screen reader. (Developer)
- Accessible mobile menus. Off-canvas menus must trap focus when open and return focus when closed. If your theme’s mobile menu doesn’t do this, look for an accessible menu plugin or a fix from your developer. (Developer)
- Skip links. Add a visible skip link that jumps to the main content for keyboard users. Some themes include this; if not, add a small link at the top of the page. (Site owner / developer)
Plugins and theme checks
- Audit plugins for accessibility. Deactivate one plugin at a time on a staging copy to identify accessibility regressions. Prefer plugins whose pages or admin UIs follow accessibility guidelines. (Developer)
- Accessibility-ready themes. Choose themes labeled “accessibility-ready” or test the theme’s front-end with basic keyboard and contrast checks. If you can’t switch theme, plan targeted fixes for problematic components. (Site owner / developer)
- Use automated scans—but don’t rely on them. Tools like WAVE or Lighthouse surface common issues quickly. Treat results as a prioritized task list, then validate manually (screen reader, keyboard, mobile). (Site owner / developer)
Technical and developer checks
- Semantic HTML and landmarks. Ensure templates use <header>, <main>, <nav>, <footer>. Landmarks help assistive tech navigate pages. (Developer)
- ARIA only when necessary. Use ARIA to enhance semantics when native HTML doesn’t provide it. Incorrect ARIA can harm accessibility—audit any ARIA usage. (Developer)
- Perform regular regression tests. Add accessibility checks to your staging checklist whenever you update plugins, themes, or WordPress core. Small changes can introduce new barriers. (Developer)
Testing checklist (quick manual tests)
- Tab through a page—can you reach and operate every control?
- Turn off images (or use a browser reader)—is content still understandable?
- Run Lighthouse/WAVE and fix high-priority failures first (forms, headings, contrast).
- Try a screen reader (NVDA or VoiceOver) on a few key pages: home, contact, product/service page.
- Test on mobile with a keyboard emulator or accessibility settings enabled.
Prioritizing work for small budgets
Start with content-level fixes (headings, alt text, link text) because they’re fast and high-impact. Next, fix forms and keyboard behavior. Reserve component-level ARIA and deep template work for a developer sprint. If you want help triaging or implementing fixes, my web development services include accessibility-focused audits and prioritized remediation plans: Web Development.
Conclusion
Accessibility improves usability for everyone and is often a modest investment with outsized returns. Use this checklist as your action plan: handle quick content fixes first, validate with simple manual tests, then schedule developer work for interactive and technical gaps. If you prefer a short audit and a prioritized fix list, reach out via the web development page to arrange a focused accessibility review.