WordPress Accessibility Implementation Guide for WCAG 2.2

Direct answer: implement WCAG 2.2 accessibility in WordPress by treating the rendered website—not the theme label, editor preview or scanner score—as the product to test. Define the pages and complete journeys in scope, build semantic templates, make every custom interaction keyboard operable, review plugin output, give editors safe patterns, and combine automated checks with manual keyboard, screen-reader, zoom and responsive testing.

This guide owns WordPress implementation evidence across themes, blocks, plugins and publishing workflows. It does not replace broader accessibility planning, legal advice or research with disabled users. A plugin, overlay or “accessibility-ready” theme cannot establish site-wide conformance by itself.

Map the WordPress accessibility surface

Start with the reusable system, not a random sample of posts. Inventory the active theme or block theme, template parts, patterns, custom blocks, page-builder widgets, shortcodes, forms, menus, search, comments, media, ecommerce or account flows, consent tools, chat, embeds and third-party scripts. Record who owns each surface and how a change reaches production.

Use this map to choose representative pages and states: a single post, page, archive, search result, 404, navigation variant, form success and error, authenticated view and any priority transaction. Recheck the map when a new plugin, block or integration is approved through the WordPress plugin governance process.

Define a testable WCAG target and scope

The official WCAG 2.2 Recommendation provides testable success criteria at levels A, AA and AAA. WordPress’s Accessibility Coding Standards expect code integrated into the official WordPress ecosystem to conform to WCAG 2.2 at level AA. Your website still needs its own approved target, scope and evidence.

Write acceptance criteria for complete pages and processes rather than isolated components. W3C’s conformance guidance explains that conformance applies to full pages and, when a page belongs to a process, to every page in that process. A usable header does not compensate for a checkout or quote form that cannot be completed.

Legal, contractual and procurement duties vary. Record the technical target separately from any legal conclusion, and obtain qualified advice before making a public compliance claim.

Generate semantic templates and landmarks

Use native HTML elements for their intended purpose: links for navigation, buttons for actions, headings for document structure, lists for grouped items and labelled form controls for input. Give the page one meaningful H1 from the template, then use H2–H6 in a logical hierarchy without selecting levels for visual size.

Identify the header, navigation, main content, complementary content and footer with appropriate elements and accessible names where needed. For block themes, WordPress documents how Group, Template Part and Query blocks can generate landmarks. Setting the main content container to <main> also supports the theme’s skip-to-content behaviour. Inspect the rendered HTML to ensure there is one main landmark and that template nesting has not duplicated it.

The WordPress block-theme accessibility guidance also documents accessibility support in the Navigation block. Core behaviour is a starting point: test the actual menu, submenu, close control and responsive state with the active theme and plugins.

Make custom interactions work without a mouse

Every control must be reachable, understandable and operable from the keyboard at each supported width. Preserve a visible focus indicator, keep focus order aligned with the reading and visual sequence, and prevent sticky headers, notices or chat buttons from covering the focused element.

For dialogs, menus, accordions, carousels and popovers, define the control’s accessible name and state, move focus only when the interaction requires it, keep focus within a modal while it is open, provide a reliable close method and return focus to the initiating control. Prefer a native element before adding ARIA. A clickable <div> does not gain correct keyboard behaviour simply because it has a role.

WordPress’s theme accessibility guidance requires theme controls to work from the keyboard across screen sizes and treats visible focus, skip links, logical headings and descriptive link text as implementation concerns.

Audit plugin and third-party output in context

Do not approve a form, menu, consent banner, booking tool, carousel, payment element or chat widget from its settings screen alone. Inspect the markup and test the complete interaction on the rendered frontend. Check the initial state, validation errors, success state, keyboard order, screen-reader announcements, zoom, mobile layout and any iframe boundary.

A plugin may be accessible in one configuration and create barriers in another. Record the version, settings and test evidence, then repeat the relevant checks after updates. If the output cannot be corrected with supported configuration, decide whether to extend, replace or remove it rather than placing an unverified accessibility badge over the problem.

Test material changes in a protected environment using the WordPress staging workflow, but repeat a focused smoke test after production deployment because caching, consent, optimisation and third-party scripts can change the final output.

Give editors safe blocks and patterns

Accessibility can regress through everyday publishing even when the theme is sound. Provide approved patterns for headings, link groups, images, callouts, tables, video and forms. Explain when an image needs useful alternative text and when a decorative image needs an empty alternative. Prevent headings used only for styling and ambiguous links such as repeated “click here.”

Use editor curation to reduce avoidable variation. WordPress’s Block Locking API can prevent specific blocks from being moved or removed, and content-only editing can preserve a pattern’s structure while allowing intended content changes. Lock only what the publishing model requires; editors still need a workable interface and a controlled route for legitimate changes.

Publishing checks can flag missing image alternatives, empty headings or unexpected hierarchy, but they must allow valid exceptions such as decorative images. Give editors short instructions, examples and an escalation path rather than relying on a warning they do not understand.

Implement forms, validation and authentication accessibly

Associate every input with a persistent label; hint text shown only inside a field is not a reliable replacement. Group related options with fieldset and legend, place instructions before they are needed, identify required fields in text and code, and accept reasonable input formats. W3C’s form-labelling tutorial explains explicit label associations and their benefits for assistive technology and larger clickable targets.

When validation fails, identify the error in text, associate it with the field, provide a useful correction, preserve valid entries and guide focus to an error summary or the first relevant problem without creating a trap. W3C’s validation guidance also distinguishes accessible client-side feedback from the server-side validation still required for security.

Allow password managers and paste, avoid unnecessary memory or transcription tasks, and test password reset, multi-factor authentication and account recovery—not just the initial login form. A CAPTCHA needs an accessible alternative and should be evaluated against less disruptive risk controls.

Verify text, language, media and responsive behaviour

Set the document language correctly and mark passages that switch language. Test reading order and direction for mixed-language content rather than treating visual mirroring as sufficient. Keep this implementation check distinct from the site’s broader bilingual architecture and translation workflow.

Provide captions or other alternatives appropriate to the media, and ensure essential information is not available only through colour, sound or an image of text. Check text and interface contrast in normal, hover, focus, error and disabled states.

At narrow widths, enlarged text and browser zoom, content and controls should reflow without clipping, overlap or loss of function. Tables that genuinely require two-dimensional layout need a deliberate small-screen treatment and clear context. Avoid fixed heights that cut off translated or enlarged content.

Combine automated and manual testing

W3C states that no evaluation tool alone can determine conformance; knowledgeable human evaluation is required. WordPress’s current accessibility testing pathway likewise combines keyboard, automated and optional screen-reader testing with reproducible reporting.

Build accessibility into the release gate

Store a regression matrix with the template or journey, viewport, browser, input method, assistive technology where relevant, expected result, actual result, owner and evidence. Run the smallest trustworthy set on every change, then expand coverage for theme, navigation, form, authentication, checkout or editor changes.

• Block a release for keyboard traps, unreachable controls, missing essential labels, unusable errors or barriers in a priority process.
• Retest the shared component so one fix does not pass on a single page while failing elsewhere.
• Verify production after deployment and record the exact version tested.
• Keep accepted exceptions visible with an owner, impact, workaround and review date.

Coordinate the accessibility checks with the broader WordPress launch checklist, while keeping this URL responsible for the accessibility implementation detail and evidence.

Report evidence without overstating conformance

Document the URLs, templates, complete processes, states, WCAG version and level, test methods, environments, findings and retest date. Separate confirmed passes, known failures, items not tested and issues that need specialist review. A percentage score is not a substitute for that scope.

The WordPress Theme Handbook explicitly says that an “accessibility-ready” tag does not mean a theme or resulting site meets WCAG AA; it means the theme reaches the Theme Review Team’s defined minimum requirements. Treat a theme, plugin or vendor statement as evidence to verify, not a transferable certification for your content and configuration.

For accessible journey and interface work, review PAKWM’s UX design service. For WordPress theme, block and plugin implementation, see website design and development. To discuss a scoped review, request a quote with priority journeys and the intended WCAG target.

Sources

• W3C: Web Content Accessibility Guidelines 2.2
• W3C WAI: Understanding Conformance
• W3C WAI: Evaluating Web Accessibility
• W3C WAI: Labeling Controls
• W3C WAI: Validating Input
• WordPress Accessibility Coding Standards
• WordPress Theme Handbook: Accessibility
• WordPress Theme Handbook: Block Theme Accessibility
• WordPress Block Editor Handbook: Block Locking API
• Make WordPress: Test for Accessibility