How to Make WordPress Accessible: WCAG Basics

Table of contents11

A restaurant owner called me on a Thursday afternoon, embarrassed. A blind customer had phoned to ask what was on the menu, because the entire menu on his website was a single image — a photo of the printed menu card — with no text alternative. To a screen reader, which is software that reads web pages aloud for people who can’t see the screen, that page was completely blank. The owner had no idea. He’d paid good money for that site.

I’m Aisha Khan, and I’ve spent years auditing WordPress sites for exactly this kind of invisible barrier. The problems are almost never malicious. They’re small, ordinary decisions — an image here, a gray button there — that quietly lock real people out.

Here’s the part that keeps me up at night: most WordPress sites fail basic accessibility checks, and the owners genuinely don’t know. The World Health Organization reports that over 1.3 billion people worldwide live with some form of disability, and they’re trying to use your site right now. This guide gives you the exact process I use to make a WordPress site accessible, based on WCAG — the Web Content Accessibility Guidelines, the world’s shared rulebook for this — broken into steps a non-developer can actually follow.

If you own or manage a WordPress site and want every visitor to be able to use it, this is for you. Let’s fix it together.

Here’s the objection I hear most: “This sounds like developer work, and I’m not a developer.” Fair. But here’s the truth: most accessibility failures on WordPress sites aren’t code problems. They’re content and choice problems — the theme you picked, the way you wrote your headings, the colors in your customizer, the images you uploaded without descriptions. You can fix the majority of them from your WordPress dashboard, without touching a line of code. This guide proves it.

Here’s what this guide covers:

• What WCAG Actually Is (and Why AA Is Your Target)
• The Four Principles Behind Every Single Rule
• Step 1: Start With Your Theme, Because It Decides Almost Everything
• Step 2: Make Sure Everything Works Without a Mouse
• Step 3: Write Alt Text That Actually Describes Your Images
• Step 4: Fix Your Heading Structure in an Afternoon
• Step 5: Check Your Color Contrast With a Free Tool
• Step 6: Make Your Forms Usable by Everyone
• Step 7: Test Like a Real Human, Not a Robot
• Frequently Asked Questions
• Final Thoughts

Ready? Let’s get started.

What WCAG Actually Is (and Why AA Is Your Target)

WCAG stands for Web Content Accessibility Guidelines. It’s published by the W3C — the World Wide Web Consortium, the same organization that defines the standards behind HTML and CSS — and it’s the closest thing the web has to a shared rulebook for accessibility. The current version is WCAG 2.2, published in October 2023.

Here’s the deal: WCAG is organized as individual testable rules called success criteria. Each one is a single statement your page either passes or fails, and each has a number — like 1.1.1 or 2.4.7 — so teams can point at exactly what’s broken. You’ll see these numbers throughout this guide, because naming the rule is half the battle.

The success criteria are grouped into three conformance levels: A, AA, and AAA. Level A is the minimum — failing these usually means some people can’t use your content at all. Level AA adds the criteria that remove the most common serious barriers: low contrast, missing focus indicators, unlabeled forms. Level AAA is the strictest, and the W3C itself says it’s not recommended as a general target for entire sites, because some content simply can’t meet all of it.

In practice, when anyone — a law, a contract, a client — says “make it accessible,” they almost always mean Level AA. That’s your target. Aim there, and you’re covering the barriers that matter most.

The Four Principles Behind Every Single Rule

Every WCAG rule sits under one of four principles, remembered by the acronym POUR. If you understand POUR, you can reason about accessibility problems you’ve never seen before, which is more valuable than memorizing rules.

Perceivable means people can perceive your content — see it, hear it, or otherwise take it in. If your only way of presenting information is a color, a blind user gets nothing; if it’s only an image, same problem. Text alternatives, captions, and good contrast all live here.

Operable means people can operate your site — click, navigate, fill in forms. Everything must work with a keyboard, because many people can’t use a mouse. No keyboard traps, no hover-only menus.

Understandable means people can understand what they’re supposed to do. Labels tell them what to type, error messages tell them what went wrong, and the site behaves predictably instead of surprising them.

Robust means your content works reliably with assistive technology — screen readers, voice control, magnifiers — today and as those tools update. This mostly means using proper, standard HTML instead of hacking things together.

I still run through POUR mentally whenever I audit a site. “Can they perceive it? Can they operate it? Is it understandable? Will their tools handle it?” Four questions, and they catch almost everything.

Bonus Tip: When you’re unsure whether something is an accessibility problem, test it with your monitor turned off and only your keyboard. If you can’t complete the task, neither can a keyboard-only user — and you’ve just found your first fix.

Step 1: Start With Your Theme, Because It Decides Almost Everything

I learned this the hard way on a client’s site years ago. We spent weeks fixing individual pages — alt text, headings, contrast — and the site still failed its audit. The theme was generating broken HTML underneath everything we did: skipped heading levels in the markup, navigation that only opened on mouse hover, form fields with no labels. We were painting over rotten wood.

Your theme controls the HTML structure of every page. A good one produces clean, semantic markup — real headings, real lists, real buttons. A bad one wraps everything in meaningless containers that screen readers can’t interpret. No amount of careful content fixes a theme that fights you.

So before anything else, evaluate your theme. Does its demo let you navigate with the keyboard? Tab through it — can you reach the menu, and does a visible outline show where you are? Do its headings follow a logical order? Check the theme’s documentation or support page for an accessibility statement. WordPress core itself follows accessibility guidelines — it includes keyboard navigation in the admin, skip links, and proper labels — but your theme and plugins can undo all of that on the front end.

If you’re choosing a new theme, this matters more than any design feature. A beautiful theme that locks people out is a liability, not an asset. For a deeper look at what separates good themes from damaging ones, read these WordPress theme mistakes that break your site — several of them are accessibility failures in disguise. And when you do switch, follow the safe process in how to install a WordPress theme the right way so you don’t break your site mid-change.

Note: I’m not going to recommend specific “accessibility plugins” as the solution here, and here’s my honest reason: scanning tools and widgets can’t repair broken theme code. They can flag problems and add surface-level helpers, but real accessibility comes from semantic HTML, keyboard support, and contrast — the things this guide teaches you to check yourself.

Step 2: Make Sure Everything Works Without a Mouse

Put your mouse aside — physically push it away — and try to use your site with only the keyboard. Press Tab to move forward through links and buttons, Shift+Tab to go back, Enter to activate a link, Space to toggle a checkbox or press a button. This is exactly how millions of people browse the web every day, including people with motor impairments, and it’s the single most revealing test you can run.

What you’re checking maps to real WCAG rules. Success criterion 2.1.1 (Keyboard) says everything you can do with a mouse must also work with a keyboard. 2.4.7 (Focus Visible) says you must be able to see where you are as you tab — that glowing outline around the focused element isn’t decoration, it’s a requirement. If your theme’s CSS removed it (a depressingly common habit), that’s a failure.

Watch for these specific problems as you tab through:

• The invisible focus. You press Tab and nothing appears to happen. The focus is moving, but there’s no visible indicator. This is the most common keyboard failure I find, and it’s usually one line of CSS that deleted the outline.
• The keyboard trap. You tab into something — a video player, a dropdown, a date picker — and you can’t tab out. You’re stuck until you reload the page. WCAG 2.1.2 explicitly forbids this.
• The hover-only menu. Your navigation dropdowns open when a mouse hovers but do nothing when focused with a keyboard. If a keyboard user can’t open the menu, they can’t reach half your site.
• The illogical order. Focus jumps from the header to the footer to a sidebar widget to the main content, in an order that matches nothing on screen. The tab order should follow the visual layout.

Fixing these ranges from trivial to technical. The trivial ones — restoring a visible focus outline, making sure menus open on focus as well as hover — are often settings or small CSS additions. The technical ones, like a trapped focus in a custom slider, may need a developer. But now you know exactly what to ask for, which is most of the battle.

This deserves its own deep dive, and there’s a full one: WordPress keyboard navigation: the accessibility guide walks through the 20-minute test and every fix in detail. For styling focus indicators yourself, the WordPress custom CSS recipes collection shows safe ways to add CSS without breaking your site.

Step 3: Write Alt Text That Actually Describes Your Images

Alt text — short for alternative text — is the text description attached to an image that a screen reader reads aloud in its place. It’s also what shows if the image fails to load, and what search engines use to understand the image. Writing good alt text is one of the highest-value accessibility skills you can learn, because it’s pure writing: no code at all.

The rule, from WCAG success criterion 1.1.1 (Non-text Content), is simple: every meaningful image needs a text alternative that serves the same purpose. But “describe the image” is vague advice. Here’s what actually works.

Describe the purpose, not just the appearance. A photo of your team on the About page isn’t there to show “five people standing” — it’s there to say “this is the team behind the company.” Good alt text: “The five-person support team smiling in our Lisbon office.” Bad alt text: “Image of people.” (Also: never start with “image of” — the screen reader already announces that it’s an image.)

Keep it short — one sentence, ideally under about 125 characters, because some screen readers cut off longer descriptions. Don’t repeat nearby text: if the caption already says it, the alt text shouldn’t say it again. And for purely decorative images — dividers, background flourishes, stock photos that add no information — leave the alt text empty. An empty alt attribute tells the screen reader to skip the image entirely, which is exactly right: announcing “decorative swirl graphic” helps nobody.

In WordPress, you add alt text in the media library or right in the image block settings when you insert an image. Make it a habit: every image gets alt text at upload time, or it doesn’t get uploaded. Future you will be grateful.

Here’s my honest confession: I used to write alt text like “chart” and move on. Then I listened to a screen reader go through one of my pages, and “chart” told the listener absolutely nothing about the data I was trying to share. For charts and graphs, summarize the key insight in the alt text — “Bar chart showing sales doubled from 2024 to 2025” — and link to a full data description if the details matter.

Step 4: Fix Your Heading Structure in an Afternoon

Screen reader users don’t read your page top to bottom like a book. They pull up a list of all the headings and jump between them — it’s their table of contents. If your headings are a mess, their navigation is a mess. This is one of the most common failures I find, and one of the easiest to fix.

The rules are straightforward. Use one H1 per page — that’s your page title, and WordPress handles it for you. Then use H2 for your main sections, H3 for subsections under those, and so on. Never skip levels: don’t jump from an H2 straight to an H4, because the screen reader user will wonder what happened to H3. And never use a heading just because you like how it looks — that’s what the block editor’s font size controls are for.

The mistake I see constantly: someone wants a big bold line of text, so they make it a heading. Or they bold a line and make it larger, when it should have been a heading. Both break the page’s outline. Headings are about structure, not appearance. If it introduces a new section, it’s a heading. If it’s just emphasized text inside a paragraph, it’s bold text.

Here’s an afternoon project that pays off enormously: open your ten most-visited pages and check the heading order. In the block editor, make sure each section title is a Heading block at the right level — the complete guide to the WordPress block editor walks through heading blocks if you need a refresher. I did this for a client with 40 pages once, and their screen-reader test user said it was the single biggest improvement we’d made. One afternoon.

Step 5: Check Your Color Contrast With a Free Tool

Low-contrast text is the single most common accessibility failure on the web — it shows up on more pages than any other issue. Light gray text on a white background looks “elegant” to a designer and is simply unreadable to anyone with low vision, an aging screen, or a phone in sunlight.

WCAG success criterion 1.4.3 (Contrast Minimum) sets the bar: normal text needs a contrast ratio of at least 4.5:1 against its background. Large text — 18pt (about 24px) or larger, or 14pt bold — needs at least 3:1. A contrast ratio is just a number describing how different two colors look, from 1:1 (identical, invisible) to 21:1 (black on white). You don’t need the math; free tools do it for you.

The usual suspects on WordPress sites: light gray body text on white (“elegant” again), placeholder text inside form fields (browser defaults are often too faint), colored buttons with white text where the brand color is too light, and white text laid over photos where parts of the image are bright. Check every one of these with a contrast checker — enter the two hex color values and read the ratio.

Also check your links. Link text needs enough contrast against the surrounding body text, not just the background — and links should never rely on color alone to be identifiable. If your links are only distinguishable by being a slightly different shade, add an underline.

Bonus Tip: When you customize colors in the WordPress customizer, test the combination before you publish it. Keep a short list of your approved color pairs and their ratios in a document. The guide to customizing WordPress without breaking it has a safe workflow for making these changes so you can experiment without risk.

Step 6: Make Your Forms Usable by Everyone

Forms are where accessibility failures hurt the most, because a broken form doesn’t just annoy someone — it stops them from contacting you, buying from you, or signing up. And forms have more ways to fail than almost any other page element.

The fundamentals, each tied to a real WCAG rule. Every input needs a visible label connected to it — that’s 3.3.2 (Labels or Instructions). Placeholder text inside the field is not a label: it disappears when you type, and many people can’t read it. Keep a real label above every field, always. Related fields — like a set of radio buttons — should be grouped so screen readers announce the question once, not once per option.

When something goes wrong, 3.3.1 (Error Identification) requires the error to be described in text, and 3.3.3 (Error Suggestion) asks you to suggest how to fix it. A red border alone fails, because color-blind users may not see it and screen readers don’t announce color. “Enter a valid email address, like name@example.com” is an error message. “Invalid input” is a shrug.

There’s a full guide to this — accessible WordPress forms: the design guide — because forms deserve the detail. The short version: label everything visibly, group related fields, write error messages that explain the fix, and never use color as the only signal.

Step 7: Test Like a Real Human, Not a Robot

Automated accessibility checkers are useful — run one, absolutely — but they catch roughly 30% of issues. They can tell you an image is missing alt text, but they can’t tell you the alt text is useless. They can measure contrast, but they can’t tell you the tab order makes no sense. The remaining 70% needs a human.

Here’s my testing routine, and I recommend it for every site owner:

First, the keyboard test. Put the mouse away and tab through your key pages: homepage, contact page, checkout if you have one. Can you reach everything? Can you see where you are? Can you complete a form and submit it? Twenty minutes, no tools needed.

Second, the screen reader test. On Windows, NVDA is free. On Mac, VoiceOver is built in — press Cmd+F5 to turn it on. Listen to your homepage. Does it make sense? Do the headings form a sensible outline? Do the images get described? This is humbling the first time — do it anyway.

Third, the zoom test. Zoom your browser to 200%. Does the layout survive, or does text overlap and buttons disappear? Many low-vision users browse zoomed in permanently.

Fourth, the phone-in-sunlight test. Take your site outside, or just turn your brightness down. Can you still read everything? This catches contrast problems no checker will flag.

Do this quarterly, and after every theme change or major redesign. Accessibility isn’t a one-time project — it’s maintenance, like backups. Small, regular, and it saves you from big painful surprises.

Frequently Asked Questions

Is WordPress accessible out of the box?

WordPress core follows accessibility guidelines — it includes keyboard navigation in the admin dashboard, skip links, and properly labeled controls. But the moment you install a theme or add plugins, the front end of your site reflects those choices, not core. Your site is only as accessible as your theme, your plugins, and your content. Treat core as a good foundation, not a finished building.

Which WCAG level should I target — A, AA, or AAA?

Target AA. Level A is the bare minimum and leaves serious barriers in place. Level AAA is so strict the W3C itself doesn’t recommend it for entire sites. Level AA covers the barriers that affect the most people — contrast, keyboard access, labels, focus indicators — and it’s what laws and contracts reference when they say “accessible.” Hit AA everywhere, then cherry-pick individual AAA criteria where they’re easy wins.

Do I need to hire a developer to make my site accessible?

Not necessarily. The steps in this guide — choosing a decent theme, writing alt text, fixing headings, checking contrast, labeling forms — need no code. You’d need a developer for structural problems: a keyboard trap in a custom slider, a menu that can’t open by keyboard, a checkout flow that breaks the tab order. Start with everything you can do yourself; you’ll be surprised how far that gets you.

Will making my site accessible hurt its design?

No — and anyone who tells you otherwise is selling something. Accessible sites aren’t ugly sites. Good contrast, clear headings, visible focus, and readable forms are just good design. Some of the best-looking sites on the web meet AA comfortably. Accessibility constrains a few choices, like which gray you use for body text, but constraints make design better, not worse.

How often should I check my site’s accessibility?

Run an automated scan monthly — it takes minutes — and do the human tests (keyboard, screen reader, zoom) quarterly and after any theme change, major redesign, or new plugin that adds front-end features. Accessibility decays over time as content gets added by people who don’t know the rules, so a short checklist for anyone who publishes on your site is worth its weight in gold.

Final Thoughts

That restaurant owner from the beginning of this guide? We added real text for the menu alongside the image, wrote proper alt text, fixed his headings, and bumped his contrast. It took an afternoon. A week later he told me a regular customer — blind since birth — had ordered online for the first time, independently. That’s what this work actually is. Not compliance. Not avoiding lawsuits. A person ordering dinner by themselves.

You now know the exact process: understand WCAG and aim for AA, remember the four POUR principles, pick a theme that doesn’t fight you, make everything keyboard-operable, write alt text with purpose, structure your headings, check your contrast, label your forms, and test like a human. None of it requires permission. All of it can start today.

One honest line: you won’t get everything perfect on the first pass, and that’s fine. Accessibility is a direction, not a destination. Every barrier you remove is a person you just let in.

If this guide helped you fix something on your site, tell me about it in the comments — I read every one, and your story might be the example that convinces the next reader to start.