WordPress Accessibility Checklist for EU Teams

Why This Matters for WordPress Sites

WordPress powers over 40% of websites in the EU, but many sites built on it fail basic accessibility checks that take hours, not weeks, to fix. The European Accessibility Act (EAA) enforcement begins June 28, 2025, and inaccessible sites create legal risk and exclude users — roughly 1 in 6 Europeans have a disability that affects web use. This checklist covers the six most common WCAG failures found on WordPress sites and how to spot and fix them yourself.

Image Alt Text

Screen reader users cannot see images. When alt text is missing, they hear nothing — they miss product photos, infographics, team members, and critical visual content. Low-vision users also lose context when images fail to load.

How to check on WordPress:

• Go to Media Library, select an image, and check if the "Alt Text" field is filled in. If it's empty, add a short description of what the image shows (20–125 characters works well).

Action items:

• Add alt text to all product images, logos, and illustrations that convey meaning
• For decorative images only, leave alt text empty (don't use "image of" or "picture" — screen readers already announce it's an image)
• Use plugin like Alt Text Assistant or manually audit using Accessibility Inspector in Firefox to find missing alt text in one scan
• Train content editors to treat alt text as required when uploading images

Color Contrast

Text that is too light or too dark against its background is hard to read for people with low vision, color blindness, or anyone viewing on a phone in sunlight. WCAG requires a contrast ratio of at least 4.5:1 for normal text.

How to check on WordPress:

• Use the WAVE browser extension (free, works in Chrome and Firefox) or axe DevTools to scan your site and see flagged contrast errors highlighted in real time.

Action items:

• Check heading and body text colors against background — gray text on white or light backgrounds is often the culprit
• Use a contrast checker tool (WebAIM, Contrast Ratio) by pasting hex color codes to verify 4.5:1 minimum ratio
• Audit your WordPress theme's CSS or use a child theme to darken text or lighten backgrounds where needed
• Test your color changes on mobile and in different lighting before publishing

Form Labels

When a form field has no label, screen reader users have no way to know what information goes in each box — is it your name? Email? Phone number? This makes forms unusable for blind and low-vision users.

How to check on WordPress:

• Use the Inspector (F12 in Chrome/Firefox) to check each form field `<input>` tag — it should have a connected `<label>` tag with matching `for` and `id` attributes.

Action items:

• In the WordPress block editor or classic editor, add a text label directly above each form field
• If using a contact form plugin (WPForms, Gravity Forms, Contact Form 7), ensure the "Label" field is filled in for every input
• Use Inspector to verify the label's `for` attribute matches the input's `id` (most plugins handle this automatically)
• Test with a screen reader (NVDA, JAWS, or built-in screen reader on your OS) to confirm each label is read aloud when you tab to the field

Link Name

Links need text that tells users where they'll go. A link that says "click here" or contains only an icon with no alt text leaves screen reader users and keyboard navigators confused about the link's purpose.

How to check on WordPress:

• Scan your page visually and listen: can you understand where each link goes from the link text alone, without reading surrounding text? Use axe DevTools to flag links with generic names like "click here," "read more," or "link."

Action items:

• Rewrite generic link text to be specific: "Read our 2024 sustainability report" instead of "click here"
• If a link is an icon or image, add alt text to that image or use a hidden text label (most accessibility plugins offer a "screen reader text" option)
• For WordPress menu items that are icons only (e.g., a shopping cart), add an `aria-label` attribute with the button's purpose — use a plugin or ask your developer if you're not comfortable editing code
• Search your site for repeated phrases like "read more" and rewrite them to unique, descriptive text

HTML Document Language

The `<html lang="">` attribute tells browsers and screen readers what language your page is in. Without it, screen readers may mispronounce words, and search engines can't serve your page to the right regions.

How to check on WordPress:

• Right-click your page, select "View Page Source," and look for `<html lang="en">` or similar near the top. If you see `<html>` with no `lang` attribute, it's missing.

Action items:

• Go to WordPress Settings → General and check the "Site Language" field — set it to your primary language (e.g., English, French, German)
• WordPress will automatically set the `<html lang="">` attribute to match this setting on all pages
• If your site is multilingual (e.g., English and German versions), use a plugin like WPML or Polylang that sets the language attribute per page

Button Name

Button elements on your site need text that describes what they do. If a button shows only an icon or has no text, screen reader users won't know what clicking it does.

How to check on WordPress:

• Look at every button on your page. Does it have visible text like "Add to Cart," "Submit," or "Download"? If it's only an icon, use Inspector to check if there's hidden text via `aria-label` or a `<span>` inside the button.

Action items:

• Add clear, action-oriented text inside every button: "Subscribe Now," "Get Started," "Learn More"
• For icon-only buttons (e.g., a menu hamburger icon), add an `aria-label="Open menu"` attribute — use a plugin or ask your developer to add this
• Test buttons with a screen reader to confirm the button's purpose is spoken aloud when focused
• Avoid buttons that say "submit" or "go" alone — pair them with context: "Submit Form," "Go to Cart"

Next Steps

Start with alt text and color contrast — these two issues appear on the majority of WordPress sites and are fastest to fix. Use free tools like WAVE, axe DevTools, and the WordPress block editor's built-in checks to audit your site in under an hour. Assign responsibility: content editors handle alt text, developers or designers handle color and HTML language, and product teams check forms and buttons. Test changes with a real screen reader before launch, and add accessibility checks to your content review workflow so new issues don't reappear.

This is technical WCAG guidance, not legal advice.