WordPress Accessibility Checklist: 20 WCAG Fixes for 2026

Web accessibility is no longer a nice-to-have. A growing number of legal complaints target small and mid-sized business websites every year, and beyond the legal risk, an inaccessible site simply locks out real visitors — people using screen readers, keyboard-only navigation, or browsing with low vision or color blindness. The good news: most WordPress accessibility problems come from a short, repeatable list of mistakes, and most of them are quick to fix once you know where to look.

This checklist covers the 20 most common WCAG (Web Content Accessibility Guidelines) issues found on WordPress sites, organized the way you’ll actually find them: content, images, forms, navigation, and color/contrast. Run your own site through our free Accessibility Checker first — it will flag many of these automatically and give you a prioritized starting point before you read further.

Images and media

1. Every meaningful image has descriptive alt text

Screen readers announce alt text in place of the image. “IMG_4021.jpg” or a blank alt attribute tells a visually impaired visitor nothing. Purely decorative images should have an empty alt="" so screen readers skip them entirely — don’t leave the attribute off completely, which can cause the filename to be read aloud instead.

2. Icon-only buttons and links have accessible names

A trash-can icon with no text is invisible to a screen reader unless it has an aria-label (“Delete item”) or visually hidden text inside it. This is one of the most common failures on WordPress sites built with page builders, where icon buttons are added purely by their visual appearance.

3. Videos have captions, and autoplay is off by default

Captions matter for deaf and hard-of-hearing visitors, and for anyone browsing with sound off. Autoplaying video or audio with no easy way to pause it is also a WCAG failure — it can drown out screen reader audio entirely.

Color and contrast

4. Text meets minimum contrast ratios

WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text against its background. Light gray text on a white background — a very common WordPress theme default — frequently fails this. Our Accessibility Checker flags specific low-contrast text so you don’t have to manually check every color combination on the page.

5. Color is never the only way information is conveyed

A form field outlined in red to show an error, with no text explaining what’s wrong, is unusable for colorblind visitors. Pair color with an icon, label, or text description every time.

6. Links are distinguishable from surrounding text without relying on color alone

An underline, bold weight, or icon alongside a different color ensures links remain identifiable for visitors who can’t perceive the color difference.

Forms

7. Every form field has a real, programmatically associated label

Placeholder text is not a label — it disappears the moment someone starts typing, and many screen readers don’t announce it reliably. Every input needs a <label> tag connected via a matching for/id pair.

8. Required fields and validation errors are announced, not just shown visually

A red asterisk alone doesn’t tell a screen reader user a field is required. Use aria-required="true" and make sure error messages are read aloud when they appear, not just displayed as colored text near the field.

9. Forms can be completed using only a keyboard

Tab through your own contact form and checkout flow from start to finish without touching your mouse. If you get stuck, lose track of where focus is, or can’t reach a submit button, so will a keyboard-only visitor.

Navigation and structure

10. Heading levels are used in order, not for visual styling

Headings should go H1 → H2 → H3 in logical document order, never skipped or chosen because “H4 just looks like the right size here.” Screen reader users frequently navigate a page by jumping between headings, and a broken hierarchy makes that navigation confusing or impossible.

11. There is exactly one H1 per page, and it describes the page’s main content

This is also a fundamental SEO best practice — our free SEO Checker flags missing or duplicate H1s on the same scan.

12. A “skip to main content” link is available for keyboard users

Without one, a keyboard or screen reader user has to tab through the entire header and navigation menu on every single page before reaching the actual content.

13. Focus states are visible when tabbing through the page

Many modern themes strip the default browser focus outline for aesthetic reasons and never replace it with a custom one. The result: a keyboard user has no visual indication of where they are on the page at all.

14. The reading and navigation order matches the visual layout

CSS can visually reposition content in ways that don’t match the underlying HTML order. A screen reader follows the HTML order, not the visual one, so a mismatch here creates a genuinely confusing experience.

Interactive elements and dynamic content

15. Custom dropdowns, modals, and accordions are keyboard-operable

A modal that only closes when you click a small X with a mouse, or a custom dropdown that doesn’t respond to arrow keys, locks out keyboard-only visitors. This is a very common gap in page-builder-generated interactive elements.

16. Modals trap focus correctly and return it on close

When a modal opens, keyboard focus should move into it and stay there until it’s closed — then return to the element that triggered it. Otherwise a keyboard user can end up tabbing through content hidden behind the modal.

17. Dynamic content updates are announced to screen readers

A “message sent” confirmation that only appears visually, with no aria-live region, is invisible to a screen reader user who has already moved focus elsewhere.

Page-level basics

18. The page has a descriptive, unique <title>

This is the very first thing a screen reader announces when a page loads, and it’s also core to SEO. Generic titles like “Home” or a repeated title across every page fail both.

19. The page’s language is correctly declared

The lang attribute on the <html> tag tells screen readers which pronunciation rules to use. WordPress sets this automatically for most sites, but custom templates or multilingual setups can accidentally override it incorrectly.

20. Tables are used for tabular data only, with proper header markup

A table used purely for visual layout confuses screen readers, which announce row and column headers to help orient the listener. Genuine data tables need <th> header cells with correct scope attributes.

Where to start

Not every item on this list carries equal weight. Start with the checks that block entire groups of visitors outright: missing form labels, keyboard traps, and contrast failures tend to have the biggest real-world impact, and they’re exactly what an automated scan catches fastest.

Run your site through the free Accessibility Checker to get a prioritized list of what’s actually wrong on your pages today, then work through this checklist for anything the automated scan can’t catch on its own — things like whether your reading order actually makes sense, or whether your custom interactive widgets are genuinely usable with a keyboard. For a full picture alongside SEO and speed, the Full Site Audit checks all three at once.