CMS Accessibility: A Practical WCAG Guide for 2026

In 2024, U.S. federal courts saw over 4,000 web accessibility lawsuits filed under the ADA — and roughly 80% of them targeted sites built on popular CMS platforms. WebAIM's annual scan of the top one million home pages tells you why: about 95% still fail basic WCAG checks, averaging around 50 detectable errors per page. Most of those errors are the boring stuff — missing alt text, low color contrast, empty links — the kind of thing a content team fixes in minutes once they know to look.

So this isn't a legal-scare post. It's a working guide. If you run a CMS and publish content, WCAG is your job now, and the good news is that most of it is learnable in an afternoon.

TL;DR — what content teams actually need to know

WCAG (Web Content Accessibility Guidelines) is the standard courts, procurement teams, and screen-reader users all point at. The current version is WCAG 2.2, published in late 2023. It's organized around four ideas — POUR: content must be Perceivable, Operable, Understandable, and Robust.

There are three conformance levels: A (bare minimum), AA (the real-world target most laws require), and AAA (aspirational, rarely mandated site-wide). Aim for AA. That's what the European Accessibility Act, Section 508, and most ADA settlements expect.

Your CMS doesn't make you compliant — it gives you tools that make compliance easy or hard. A good CMS offers alt-text fields, semantic heading output, keyboard-accessible admin, and themes with decent contrast. It can't stop you from writing "click here" links or skipping from an H2 to an H4. That part's on you.

If you're also thinking about how images affect both accessibility and search, our guide on image SEO for blogs covers alt text from the ranking side — the two goals overlap almost perfectly.

Is my CMS responsible for accessibility, or am I?

Both, but not equally. The CMS is responsible for the structural output — clean HTML, real headings, focusable controls, form labels tied to inputs. You're responsible for the content decisions — what the alt text says, whether headings are in order, if a link makes sense out of context. A CMS can hand you a loaded gun or a locked one; you still pull the trigger.

Think of it as a split. The platform sets the floor. The content team sets the ceiling. A great CMS on a lazy team fails an audit. A mediocre CMS with a trained team can pass AA. If you want to understand what "gives you good tools" means at the platform level, we broke that down in what makes a CMS developer-friendly — accessibility is one of the quieter markers of a well-built platform.

What are the WCAG 2.2 basics I keep hearing about?

WCAG 2.2 has 87 success criteria, but you don't memorize them — you learn POUR and the handful of criteria content teams hit daily. Perceivable: can people sense the content (alt text, captions, contrast)? Operable: can they use it without a mouse (keyboard nav, focus visible, enough time)? Understandable: is it predictable and clearly labeled (form labels, consistent navigation, readable language)? Robust: does it work with assistive tech (valid HTML, correct ARIA)?

WCAG 2.2 added nine new criteria over 2.1. The ones a content team notices: Focus Not Obscured (a sticky header can't hide the focused element), Target Size (interactive targets at least 24×24 CSS pixels), and Dragging Movements (anything you drag needs a click alternative). These are mostly theme and design concerns, not writing concerns — but if your site fails them, a lawsuit letter doesn't care whose fault it was.

What are the WCAG conformance levels — A, AA, AAA?

Three levels, each stricter than the last. Level A is the minimum: without it, some people simply can't use your site. Level AA is the practical target — it's what most laws and contracts require. Level AAA is the gold bar; W3C itself says you can't reasonably hit AAA on all content, so nobody demands it site-wide. Pick AA and hold it.

Here's how the levels break down on the criteria content teams touch most:

The takeaway: contrast tightens sharply at AAA (7:1 is hard to design around), and AAA asks for sign-language video and a low reading grade — reasonable for a government portal, overkill for a blog. AA is the honest line to hold.

Where does a CMS help — and where does it quietly hurt?

A CMS helps when it ships an alt-text field on every image upload, forces or nudges correct heading order in the editor, exposes form-label fields, and renders real semantic HTML (<nav>, <main>, <button> — not a <div> pretending to be a button). It hurts when the theme ships 3:1 body text, the rich-text editor lets you fake a heading with bold text, or the admin itself can't be operated by keyboard so your editors with disabilities can't even publish.

The sneaky failures are almost always in the theme, not the core CMS. A platform can output perfect structure and still ship a low-contrast color palette that fails AA on day one. Check the theme, not just the platform. If speed matters to you too, note that many accessibility fixes (semantic HTML, fewer layout tricks) also help Core Web Vitals on CMS sites — lean, correct markup is fast markup.

The content team accessibility checklist

Run this on every post and page before you publish. It covers the WCAG AA criteria a writer or editor actually controls — no code required.

1. Alt text on every meaningful image. Describe what the image shows and why it matters, in 5–15 words. Decorative-only images get empty alt (alt="") so screen readers skip them — don't describe a background flourish.
2. Headings in order. One H1 (your title), then H2s for sections, H3s nested under them. Never skip a level (H2 → H4) and never fake a heading with bold text.
3. Color contrast at 4.5:1. Body text against its background must hit 4.5:1 (3:1 for large text). Check it with a contrast tool before shipping a new theme color.
4. Descriptive link text. "Read the 2026 pricing guide" — not "click here" or "read more." Screen-reader users pull up a list of links out of context; each one must make sense alone.
5. Keyboard test. Tab through the page. Every link, button, and form field must be reachable, and the focus outline must be visible. If your Tab key gets stuck, so does a keyboard-only user.
6. Form labels tied to inputs. Every field needs a visible <label>. Placeholder text is not a label — it vanishes when you type.
7. Captions on video. Any embedded video with speech needs captions. Auto-generated is a start; corrected is AA.
8. Language set. The page's <html lang="en"> (or your language) tells screen readers how to pronounce it. Most CMSes set this once — confirm it's right.

Do these eight and you clear the large majority of the errors WebAIM finds on the average page.

Common failures and their fixes

Most audit findings repeat. Here's the short list of what gets flagged and how to close it:

Notice how many of these live in the content, not the code. That's the point: buying an accessible CMS doesn't finish the job, but a CMS that surfaces these fields makes the job small.

How UnfoldCMS handles accessibility (honestly)

Full disclosure: I work on UnfoldCMS, and this post lives on its blog. So here's the honest version, not the sales version.

The admin panel has a strong accessibility foundation. UnfoldCMS is a self-hosted Laravel + React app, and its admin UI is built on shadcn/ui, which sits on top of Radix primitives. Radix is built for keyboard navigation, focus management, and correct ARIA out of the box — so dialogs trap focus properly, menus are arrow-key navigable, and controls announce themselves to screen readers. That means an editor who relies on a keyboard or a screen reader can actually operate the back office.

The media library supports alt text on every image, so criterion 1.1.1 is a filled-in field, not a code edit.

What I won't claim: UnfoldCMS is not "WCAG AAA certified" — no CMS honestly is, because conformance is a property of your finished site, not the software. It does not ship an automated accessibility checker. And the public site's accessibility depends on your theme. The default aurora template renders semantic HTML and readable contrast, but the moment you customize colors or build a new theme, AA is back in your hands. The CMS gives you the tools — alt-text fields, semantic output, a keyboard-accessible admin. Passing WCAG is still on the site builder. Any vendor telling you otherwise is selling you something.

FAQ

Does WCAG 2.2 replace 2.1, and do I need to redo everything? No panic. 2.2 is backward-compatible — it adds nine criteria and removes none (well, it deprecates one about parsing). If you met 2.1 AA, you're close; just check the new ones like target size and focus-not-obscured, which are mostly theme fixes.

Is AA legally required? In practice, yes for most cases. The ADA (via DOJ guidance), Section 508, and the European Accessibility Act all point at WCAG AA. Courts settle ADA web suits against the AA bar. AAA is almost never demanded.

Can I just install an accessibility overlay widget and be done? No. Overlay widgets (the little floating accessibility button) don't fix underlying code and have drawn their own lawsuits. Real fixes live in the HTML and content, which is exactly what this checklist covers.

Who's responsible if my site gets sued — me or my CMS vendor? You, the site owner. The CMS is a tool. Compliance is a property of what you publish with it. That's why picking a CMS that surfaces alt text, semantic headings, and a keyboard-accessible admin matters — it lowers the effort, but the duty stays with you.

How do I test contrast and keyboard access without special software? Contrast: use a free color-contrast checker (WebAIM has one). Keyboard: unplug your mouse and Tab through the page. Both take five minutes and catch most AA failures.

Ship accessible content without fighting your tools

Accessibility isn't a project you finish — it's a habit you build into publishing. The eight-item checklist above turns WCAG from a legal abstraction into a pre-publish routine. Pick a CMS that puts those fields in front of your writers instead of burying them in code, and AA stops being scary.

If you want a self-hosted CMS with a keyboard-accessible admin, alt-text fields on every image, and semantic output you can build an accessible theme on top of, take a look at what UnfoldCMS ships. Bring your own theme discipline, and it'll meet you halfway.

Sources: WCAG 2.2 and Understanding WCAG (W3C Web Accessibility Initiative); WebAIM Million annual accessibility report (webaim.org/projects/million); U.S. ADA web accessibility lawsuit trend data. Conformance levels and success criteria reflect WCAG 2.2, published December 2023. Verify current legal requirements for your jurisdiction — this is guidance, not legal advice.