Guru Site HealthAccessibility
Checking a WordPress site for accessibility.
Most accessibility problems on a WordPress site are not in the theme. They are in the content, which means you can fix them yourself, today, without a developer. Here is what to look for and how to find it.
One framing note before the list. Accessibility is usually sold either as a legal threat or as a moral lecture, and both get tuned out. The practical version: roughly one in five people has a disability of some kind, your content is already written, and the fixes below mostly take seconds each. The same work also makes your pages clearer for search engines, which read a page in a way not unlike a screen reader.
1. Missing alt text
The most common accessibility failure on the web, and the easiest to fix.
Alt text is the description read aloud when someone cannot see the image. Without it, a screen reader announces “image”, or reads the filename, which is how people end up listening to “IMG underscore 2847 dot jpeg”.
How to find it: open Media → Library, switch to list view, and click through items.
Tedious but thorough. For a whole-site view, use a checker plugin, or simply view the source of your key
pages and search for <img without an alt.
How to write it: describe what the image conveys, in a sentence, in context.
| Instead of | Write |
|---|---|
alt="image" | alt="Two people reviewing a site audit on a laptop" |
alt="DSC_0041.jpg" | alt="The finished oak table, from above" |
alt="chart" | alt="Site score rising from 48 to 81 over six weeks" |
The exception people get wrong: purely decorative images should have an empty alt
attribute — alt="" — not a missing one and not a description. Empty tells a
screen reader to skip it. Missing makes it guess. Describing a decorative swirl is worse than silence.
2. Heading order
Headings are a document outline, not a set of font sizes. Screen reader users navigate by jumping between them, and an outline that skips levels is a table of contents with pages torn out.
Two rules:
- One H1 per page, and it should be the page or post title.
- Do not skip levels going down. H2 then H3 is fine. H2 then H4 is not.
The usual cause is choosing a heading because of how big it looks. If H3 is the right level but the wrong size, that is a CSS problem, and the fix belongs in CSS.
How to check: the free WAVE browser extension draws the outline for you. Or in the block editor, open the document overview panel — it lists your headings and warns about skipped levels.
3. Link text that means nothing alone
Screen readers can list every link on a page. A page with “read more” eleven times produces a list of eleven identical entries.
Write links that describe their destination:
- Instead of Click here to see our pricing, write See our pricing.
- Instead of Read more, write Read the full audit checklist.
- Avoid using a bare URL as link text; it gets read character by character.
4. Form fields without labels
Every input needs a real <label> associated with it. Placeholder text is not a
label: it vanishes the moment someone types, it is usually too low-contrast, and many screen readers do
not announce it at all.
Check your contact form, your search field and your comment form. Contact form plugins vary a great deal in how well they do this.
5. Colour contrast
Text needs enough contrast against its background to be read by someone with low vision, or anyone outdoors on a phone. The thresholds:
| Text | Minimum ratio |
|---|---|
| Normal body text | 4.5 : 1 |
| Large text (18pt+, or 14pt+ bold) | 3 : 1 |
| Interface components and icons | 3 : 1 |
The usual offenders are light grey captions, placeholder text, and pale text over a photograph.
If your text sits on a semi-transparent panel over a background, the ratio must be calculated against the composited colour — what the eye ends up seeing — not against the panel colour in your stylesheet. Getting this wrong in either direction is common: it produces both false passes and imaginary failures.
6. Keyboard navigation
The fastest meaningful test on this page, and it takes a minute.
Load your home page, put the mouse down, and press Tab repeatedly. Watch for:
- Can you see where you are? There should be a visible outline on the focused element at every
step. If a theme has
outline: nonewithout a replacement, keyboard users are navigating blind. - Can you reach everything? Menus, buttons, form fields, the search box.
- Can you get out of things? Open a modal or a dropdown and try to leave it.
- Does the order make sense? It should follow the visual layout, not jump around.
- Is there a skip link? The first Tab on a well-built site usually reveals “Skip to content”, so a keyboard user does not traverse the whole menu on every page.
7. The page language
Your <html> tag should carry a lang attribute. Screen readers use it
to choose pronunciation rules; without it, English can be read with the wrong phonetics entirely.
WordPress sets this from your site language, so it is usually right — but custom themes
occasionally hard-code it or drop it.
What automated checking can and cannot do
Worth being straight about. Automated tools reliably catch perhaps a third of real accessibility problems. They are very good at the mechanical ones:
- Missing alt attributes
- Skipped heading levels and multiple H1s
- Contrast ratios below threshold
- Inputs with no associated label
- A missing page language
They cannot judge whether your alt text is accurate, whether your link text is meaningful, whether your tab order is sensible, or whether your error messages explain anything. Those need a person.
Which is an argument for automation, not against it: let the tool take the mechanical third off your plate so your attention goes to the two-thirds that need judgement. Guru Site Health checks the mechanical set as part of its accessibility area — alt text, heading structure, page language and related — and scores it alongside the rest of the site.
Widgets that promise to make a site compliant with one line of JavaScript are widely criticised by disability advocates and by accessibility professionals, and have featured in lawsuits rather than preventing them. They cannot fix wrong alt text, because they do not know what the image shows. Fix the content.
If you do five things
- Add alt text to every meaningful image, and
alt=""to decorative ones. - Make sure every page has exactly one H1 and no skipped levels.
- Tab through your home page and confirm you can see where focus is.
- Check your contact form fields have real labels.
- Fix any body text under 4.5:1 contrast.
That is most of the mechanical problem, and none of it requires touching PHP.
Frequently asked questions
What is the most common WordPress accessibility problem?
Missing alt text on images, by a wide margin. It is also the easiest to fix and the one most directly under a site owner’s control, since it is content rather than code. Describe what the image conveys in context, and use an empty alt="" for purely decorative images.
Should decorative images have alt text?
They should have an empty alt attribute, alt="", which tells a screen reader to skip them. That is different from having no alt attribute at all, which makes the reader guess and often announce the filename. Describing a decorative border is worse than saying nothing.
Can a plugin make my WordPress site accessible?
A plugin can find the mechanical problems — missing alt attributes, skipped headings, low contrast, unlabelled inputs. It cannot judge whether your alt text is accurate or your link text is meaningful. Automated checking catches roughly a third of real issues, which is worth having as long as you do not mistake it for the whole job.
Are accessibility overlay widgets worth using?
They are widely criticised by disability advocates and accessibility professionals, and have featured in lawsuits rather than preventing them. A script cannot know what an image depicts, so it cannot write correct alt text. Fixing the underlying content is the only approach that actually works.
What contrast ratio does text need?
4.5:1 for normal body text and 3:1 for large text (18pt and above, or 14pt bold and above) and for interface components. Measure against the colour actually behind the text — if it sits on a semi-transparent panel, use the composited result, not the panel colour from your stylesheet.
How do I test keyboard accessibility?
Load a page, stop using the mouse, and press Tab repeatedly. You should always be able to see which element has focus, reach every interactive element, escape from menus and modals, and move in an order that matches the visual layout. It takes a minute and finds problems no scanner reports.
Find these on your own site in about ten seconds
Guru Site Health runs 32 checks across updates, security, database, media, accessibility and SEO, and gives you one score. Thirteen of the findings can be fixed from the dashboard in one click, and every fix can be undone. It makes no external requests — nothing about your site ever leaves it.