WordPress accessibility for agencies: WCAG guide

1. Why accessibility matters in an agency project

In many contexts it is a legal requirement, not just good practice. Sites for public administration, institutions, universities and companies above certain thresholds must comply with WCAG 2.1 or 2.2 under European regulation (EN 301 549).

Beyond compliance, an accessible site is usually more technically solid: semantic HTML, clear navigation, consistent alt text. These are also things that help search engines and make the code easier to maintain over time.

2. Semantic HTML: the foundation that changes everything

Most accessibility problems come from HTML using generic elements where specific semantics are needed. A clickable div is not a button. An h3 chosen for its font-size is not a heading.

Elements that make a real difference:

button for all interactive elements (not div or span with onclick).
nav, main, footer, aside, article for page structure.
h1 through h6 in hierarchical order, chosen for meaning not visual size.
label correctly linked to every form field.
Descriptive alt text on informative images, empty (alt='') on purely decorative ones.

3. Keyboard navigation and focus management

An accessible site is fully navigable by keyboard. Every interactive element — links, buttons, form fields, menus — must be reachable and operable using Tab and Enter.

What to verify in practice:

The focus order follows the logical page order, not the visual position of elements in CSS.
The focus indicator (outline) is visible on all interactive elements. It should never be removed with outline: 0 without an equally visible replacement.
Panels and modals that open must correctly trap focus: Tab should not be able to leave the modal while it is open.
When a modal closes, focus returns to the element that triggered it.

4. Contrast, ARIA and images

Contrast: text on background needs at least 4.5:1 for regular text and 3:1 for large text (above 18pt or 14pt bold). Interactive buttons and icons follow the same criterion.

ARIA should be used sparingly. The attributes role, aria-label, aria-describedby and aria-expanded belong where semantic HTML is not sufficient. Adding ARIA on already incorrect markup makes things worse rather than better.

A concrete example: a button that opens a panel needs aria-expanded='true' or 'false' to communicate its state to screen readers. Without that attribute, someone using a screen reader cannot tell whether the panel is open or closed.

5. How to test accessibility in a WordPress project

Automated tools (axe, Lighthouse, WAVE) catch a portion of issues — estimated between 30 and 40% of the total. The rest requires manual checking.

A reasonable minimum test for an agency project:

Full keyboard navigation: no element reachable only with a mouse.
Contrast check with a dedicated tool (Colour Contrast Analyser or browser inspector).
NVDA on Windows or VoiceOver on Mac/iOS walkthrough of main user flows: homepage, contact form, navigation.
HTML markup validation and structural heading review.

Frequently asked questions

Are WordPress builders accessible?

It depends on how they are used. Their output is not always optimal, but with attention to the HTML they generate and the available ARIA settings, a good level of conformance is achievable.

Is WCAG 2.2 legally required?

In Europe, EN 301 549 requires AA conformance for public bodies and public service concessionaires. For private sites there is no generalised mandate yet, but European directives are progressively widening the scope of obligated parties.

Does accessibility slow development down?

When built into the process from the start, much less than people expect. The most expensive problems appear when accessibility is treated as a separate audit at the end, not when it is part of ordinary development.

Next step

Working on a WordPress project with accessibility requirements?

I can assess the current level and support the team in making the necessary changes, integrated into the development process.

Talk about the project