WordPress Accessibility Audit: 12 Practical WCAG 2.2 Checks for Business Websites
A website can look polished and still be difficult to use. A visitor may be unable to open the mobile menu with a keyboard, understand an error in a contact form, or read pale text over a bright background. These are not merely design details: they can prevent people from finding information and contacting your business.
A WordPress accessibility audit helps identify these barriers before they become part of a redesign, a campaign landing page, or a new website launch. You do not need to begin with a full technical overhaul. Start with the pages that matter most to customers, test how real people interact with them, and prioritize issues by impact.
This guide offers 12 practical checks aligned with relevant parts of WCAG 2.2. It is a useful first-pass checklist, not a complete WCAG conformance audit, legal opinion, or certification.
What should a WordPress accessibility audit cover?
Review at least four representative page types: your homepage, a service page, a lead-generation/contact page, and a longer article or resource. If your website has checkout, booking, account creation, or other critical journeys, add those too. Include desktop and mobile views, keyboard-only use, and assistive-technology testing when feasible.
Record each finding with the page URL, affected component, steps to reproduce, user impact, proposed fix, owner, and retest result. A simple shared spreadsheet is enough to start.
12 accessibility checks to run on your WordPress website
1. Navigate every essential action using only a keyboard
Put your mouse aside. Press Tab to move through links, buttons and form controls, use Shift+Tab to move backward, and activate controls with the appropriate keyboard key. Check the main navigation, search, cookie banner, contact form, and footer. A dropdown that works on hover but not with a keyboard needs attention.
Pass evidence: Every essential action can be reached and operated without a mouse, with a sensible focus order. See the W3C’s first accessibility review guidance.
2. Make keyboard focus visible—and keep it on screen
Users should always be able to tell which link or button is selected. Look for themes or custom CSS that remove focus outlines without a suitable replacement. Test sticky headers, floating chat widgets and cookie banners: they should not completely hide the focused control. WCAG 2.2 adds Focus Not Obscured (Minimum) at Level AA.
Pass evidence: A visible focus indicator follows keyboard navigation, and overlays do not entirely cover the focused component.
3. Test menus, accordions and popups in their open and closed states
Interactive components can fail even when the underlying page is accessible. Open the mobile menu, expand FAQs, launch a modal, and close each using the keyboard. For a modal dialog, focus management and return focus deserve particular attention. In Beaver Builder, test the rendered module behavior, not only how it looks inside the editor. Third-party add-ons may handle keyboard interactions differently.
Pass evidence: The component announces its purpose and state appropriately, can be operated without a pointer, and does not trap the user unexpectedly.
4. Give every form control a real label
Placeholder text is not a reliable substitute for a label. A contact form’s name, email, phone, file upload and consent controls should have clear programmatically associated labels. If a field requires a special format, provide instructions before users submit. The W3C forms labeling tutorial explains how labels connect to controls.
Pass evidence: Clicking a visible label focuses its field where appropriate, and assistive technology can identify the control. Check any Gravity Forms or other form-plugin customizations on the live rendered page.
5. Make form errors understandable and recoverable
Submit a blank required form, enter an invalid email address, and trigger a validation error. The message should identify the problem in text, indicate the affected field, and help the visitor correct it. Do not communicate errors by red borders alone. After a failed submission, check that the user can discover the errors without hunting around the page.
Pass evidence: Errors are explained in words, associated with relevant fields, and can be corrected without losing previously entered information unnecessarily.
6. Measure color contrast rather than judging by eye
Subtle gray text and mint-colored buttons can look elegant but may be difficult to read. For WCAG 2.2 Level AA, ordinary text generally needs at least 4.5:1 contrast against its background; qualifying large text generally needs 3:1. Non-text controls and their states have separate contrast considerations. Test real color combinations, including hover, disabled and error states, rather than checking a brand palette in isolation.
Pass evidence: Document the measured contrast ratios for key text and interface states. Use the WCAG 2.2 Quick Reference to check exceptions and the applicable criterion.
7. Check zoom, text resizing and narrow-screen reflow
Increase browser zoom and test a narrow viewport. Content should remain readable and functional without unnecessary horizontal scrolling. WCAG’s reflow criterion addresses content at a width equivalent to 320 CSS pixels, with exceptions for content that genuinely requires a two-dimensional layout. Check pricing tables, sticky buttons, long URLs, form fields and multi-column sections.
Pass evidence: Main content and controls remain usable when enlarged, with no clipped text or inaccessible actions. See the W3C’s Reflow explanation.
8. Make small touch targets easier to activate
On mobile, inspect tiny close icons, carousel arrows, menu toggles and links packed close together. WCAG 2.2’s Level AA Target Size (Minimum) criterion generally uses 24 × 24 CSS pixels, subject to defined exceptions including spacing. Larger comfortable targets can still be a sensible design choice.
Pass evidence: Important controls meet the criterion or an applicable exception and are practical to tap on real devices.
9. Check headings, landmarks and link purpose
A visually large sentence is not automatically a heading. Review the page structure so users can navigate sections through meaningful headings. Use descriptive link text such as “View website maintenance options” rather than a series of indistinguishable “Click here” links. Check that navigation and main-content landmarks make sense, especially when templates and page-builder rows are combined.
Pass evidence: Headings describe the content beneath them, repeated navigation is understandable, and links make sense in context.
10. Write image alternatives according to purpose
Images that convey information need an equivalent text alternative. A linked image should communicate the link’s purpose; a chart may need a longer explanation nearby. A purely decorative image generally needs an empty alt attribute, not a keyword-stuffed description. The W3C’s alt-text decision tree is a practical guide.
Pass evidence: Important images convey their meaning without sight, while decorative images do not create unnecessary announcements.
11. Review video, audio and motion controls
If a page uses product demos, testimonials or animated banners, check whether captions, transcripts, audio descriptions or other alternatives are needed for the content. Users should be able to pause or control moving content when the relevant criteria apply. Avoid essential instructions that exist only inside a silent video or only in audio.
Pass evidence: The information and controls remain accessible to people who cannot see or hear the original media.
12. Test third-party widgets and the complete enquiry journey
A site can pass basic checks until a visitor opens a chat widget, CAPTCHA, calendar embed or external booking tool. Test these components alongside the full route from a service page to a successful enquiry. If a third-party tool introduces a barrier, document it and work with the vendor or select an alternative rather than assuming a WordPress plugin can fix it automatically.
Pass evidence: A visitor can complete the highest-value task from beginning to end, including any embedded service.
How to prioritize the fixes without delaying every project
Not every finding has the same business or user impact. Use a small triage table:
| Priority | Example | Recommended action |
|---|---|---|
| Critical | Contact form cannot be completed by keyboard | Fix before launch; retest the entire journey |
| High | Mobile menu or modal cannot be closed | Assign a near-term fix and verify with keyboard |
| Medium | Low-contrast supporting text on a key page | Correct within the design QA cycle |
| Review | Unclear alt text on a nonessential image | Confirm its purpose and update appropriately |
These are illustrative priorities; severity depends on context. Track an owner, a due date and a retest result for each issue. If you are commissioning a redesign, add accessibility acceptance criteria to the brief so the work is not treated as an unexpected add-on.
What automated WordPress accessibility plugins can—and cannot—do
Automated scanners can flag some missing labels, contrast issues and structural errors. They cannot reliably determine whether every image alternative conveys the right meaning, whether a complex interaction makes sense, or whether a real person can complete a task. An accessibility overlay is not a substitute for accessible design, development and testing.
For WordPress sites using Beaver Builder, Gravity Forms or multiple third-party modules, combine automated checks with manual keyboard testing and, where practical, assistive-technology review. Retest after significant theme, plugin or template changes. Accessibility is an ongoing quality practice, not a one-time badge.
Frequently asked questions
Does a WordPress accessibility audit guarantee WCAG 2.2 compliance?
No. This checklist is an initial review, not a complete conformance assessment. Formal evaluation requires a defined scope, appropriate expertise and more comprehensive testing. Legal obligations vary by jurisdiction and context.
Will accessibility improvements automatically increase Google rankings?
No specific ranking improvement is guaranteed. Clear structure and usable content can support better user experiences, but search performance depends on many factors. Treat accessibility as a responsibility to users, not a shortcut to SEO results.
Can I make an existing Beaver Builder website more accessible?
Often, yes. Many issues can be improved through content, module settings, CSS and targeted development. Complex widgets may require deeper fixes or replacement. Test the rendered website after each change.
Which pages should a small business audit first?
Start with the homepage, primary service page, contact form and any booking or checkout flow. Add popular articles, downloads and pages used by advertising campaigns next.
Build accessibility into your next website improvement
Accessible websites begin with ordinary decisions made carefully: readable text, clear forms, keyboard-friendly interactions and layouts that still work when enlarged. A documented audit helps you find the biggest barriers and commission the right fixes.
Explore Webgeek’s WordPress website development services, see our SEO and website improvement approach, or share your website requirements to discuss a practical improvement plan.
