Accessibility and Your CMS: What a Platform Can Do

Why accessibility belongs in a platform decision

An accessible website can be used by people with disabilities, including people who move through pages with a keyboard, use a screen reader, magnify the screen or need captions. In the United States, the Department of Justice's guidance on web accessibility says "The ADA requires that businesses open to the public provide full and equal enjoyment" of their goods and services, and that this applies to websites. The same guidance says businesses "have flexibility in how they comply," and that existing technical standards, including the Web Content Accessibility Guidelines (WCAG), "provide helpful guidance."

The guidance was published on March 18, 2022. The page notes that it does not reflect the separate 2024 rule for state and local governments, which covers public bodies rather than private businesses. This guide is general information, not legal advice; if you have specific obligations, ask a lawyer.

What WCAG 2.2 is

WCAG is the W3C's standard for web accessibility. Version 2.2 became a W3C Recommendation on October 5, 2023. It is organized into success criteria at three levels, A, AA and AAA, and level AA is the level this site aims for. The W3C's summary of what is new in 2.2 lists criteria about visible keyboard focus, minimum target sizes for controls, dragging movements, consistent help and accessible authentication.

What the platform controls

The platform decides some things you cannot easily change:

The editor: whether it prompts for image descriptions (alt text), lets you set real headings and produces clean, structured markup.
Built-in components: menus, forms, sliders, checkout pages and pop-ups supplied by the platform or its apps.
Hosted checkout and account pages on commerce platforms, which you may not be able to edit at all.

What the theme or template controls

Several accessibility problems sit in the design layer:

color contrast between text and background;
whether keyboard focus is visible when tabbing through links and buttons;
the size of buttons and links on phones;
whether menus and pop-ups can be opened and closed with a keyboard;
how the layout behaves when text is enlarged.

Two sites on the same platform can differ completely here, depending on the theme. That makes the theme choice as important as the platform choice.

What you control as the editor

Content decisions are entirely yours:

Write descriptive link text ("read the pricing guide", not "click here").
Use headings in order, as an outline, not for visual size.
Add alt text that describes the purpose of each meaningful image, and leave decorative images without it.
Caption videos and provide transcripts for audio.
Keep forms short, with clear labels and error messages that explain how to fix the problem.
Avoid putting important text inside images.

Questions to ask before you choose

Whether you are choosing a platform, a theme or a developer, ask:

Does the theme or template vendor publish an accessibility statement, and what standard does it claim?
Can every menu, form and pop-up be used with a keyboard alone? Try it yourself with the Tab key.
Does the editor make it easy to add alt text and set proper headings?
On commerce platforms, how accessible are the checkout and account pages you cannot edit?
Has anyone tested the finished site with assistive technology, and with which tools?

The last question matters. Automated checkers catch only part of the picture; testing with a keyboard and with screen readers, and ideally with disabled users, finds problems tools miss.

Accessibility by platform type

The same principles apply everywhere, but where the work falls depends on the kind of platform.

Hosted builders such as Wix, Squarespace and Webflow control the underlying markup of their components. You choose templates and sections, and you write the content. Your main levers are choosing a template whose menus, forms and buttons work with a keyboard, checking color contrast in your chosen style, and writing good alt text and headings. If a built-in component causes a problem you cannot fix, report it to the platform and consider an alternative component.

Commerce platforms such as Shopify add checkout and account pages that you may not be able to edit at all. Test those pages with a keyboard before launch, because a checkout that cannot be completed without a mouse locks out customers.

Self-hosted software such as WordPress, Drupal and Joomla gives you full control, which means accessibility depends heavily on the theme and plugins chosen and on the developer's care. Ask for keyboard testing and contrast checks as part of any build, and recheck after adding plugins that insert pop-ups, sliders or forms.

Headless systems leave the whole front end to your developer, so accessibility is entirely a matter of how they build it.

Common problems and quick fixes

Frequent accessibility problems on small business sites and what to do
Problem	Who can fix it	First step
Low-contrast text on buttons or over photos	You or your designer	Darken the text or add a solid background behind it
Images with no alt text	You, as editor	Add a short description of what the image shows or does
Headings chosen for size, not structure	You, as editor	Use one main heading, then headings in order
Menus that cannot be opened with a keyboard	Theme or platform	Switch theme or report it to the vendor
Form errors shown only in red	Theme, plugin or platform	Choose a form tool that writes the error in words next to the field
Pop-ups that trap focus or cannot be closed	Plugin or app	Remove the pop-up or replace it with one that supports keyboard users

Keeping accessibility up after launch

Accessibility is easiest to lose through small changes: a new pop-up, an image added without alt text, a color tweak on a button. Add three quick checks to your editing habits: describe every new image, keep headings in order, and tab through any new form or widget before publishing it.

Writing an accessibility statement

An accessibility statement tells visitors what you have done, what you know is not yet right and how to reach you. It does not need legal language. A useful statement covers:

the standard you are aiming for, such as WCAG 2.2 level AA;
how the site was checked, and with which tools or methods;
what has not been tested yet, stated plainly;
known problems and any workaround, such as offering information by email;
a contact address for reporting problems, and what you will do with reports.

Keep it honest. A statement that claims full compliance without testing can mislead the very people it is meant to help.

A practical starting checklist

Tab through your homepage, contact page and checkout. Can you see where you are at every step, and reach everything?
Zoom the browser to 200% and check that nothing overlaps or disappears.
Run an automated checker on key pages and fix the issues it flags.
Check text contrast on buttons and over images.
Review every image's alt text on your top ten pages.
Publish an accessibility statement that says what you have and have not tested, and how people can report problems.

You can see how we describe our own testing, and its limits, on our accessibility page.

Sources for this page

U.S. Department of Justice, ADA.gov (March 18, 2022): Guidance on Web Accessibility and the ADA. Official source, read November 4, 2026.
W3C (Recommendation, October 5, 2023): Web Content Accessibility Guidelines (WCAG) 2.2. Official source, read November 4, 2026.
W3C Web Accessibility Initiative: What's New in WCAG 2.2. Official source, read November 4, 2026.