Accessibility CMS Features That WCAG and ATAG Require

Image

A CMS doesn’t make your site accessible. It either enables or limits your ability to build and maintain accessible content. That distinction is more important than any vendor claim.

Two standards govern the conversation:

• Web content accessibility guidelines (WCAG) set requirements for what visitors experience on the published site.
• Authoring tool accessibility guidelines (ATAG) set requirements for the authoring tool itself.

Most "accessibility CMS" searches conflate the two and end up comparing platforms on the wrong criteria.

No CMS ships compliant out of the box. Not WordPress or Drupal. Compliance is an outcome of how your team designs, builds and governs content within the constraints a platform provides.

Overlays don't change this. They sit on top of a page and attempt to patch issues at render time. In practice, they often introduce new barriers: breaking focus order, interfering with screen readers and creating keyboard traps.

The Department of Justice and accessibility advocates have repeatedly pushed back on overlay claims.

What a CMS can do is give your team the right constraints and workflows. Let’s map those constraints to the standards that require them.

What makes a CMS accessible

Accessibility requirements are split across two standards: WCAG and ATAG.

WCAG governs what visitors encounter on the published site. It organizes requirements under four principles:

• Perceivable means content must be presented in ways users can detect, whether through sight, hearing or touch.
• Operable means every interaction must work via keyboard, voice or other input methods beyond a mouse.
• Understandable means interfaces and content must behave predictably with clear language and consistent navigation.
• Robust means markup must be clean enough for assistive technologies to interpret reliably now and as those tools evolve.

Most procurement mandates reference WCAG 2.1 AA or 2.2 AA as the target conformance level.

ATAG governs the CMS itself:

• Part A covers whether content creators with disabilities can use the authoring interface. That means keyboard navigation through every admin panel, sufficient contrast in the editing UI and compatibility with assistive technology.
• Part B covers whether the tool helps all authors produce accessible output. Think required alt text fields, heading structure validation and link text warnings.

Regulatory frameworks map back to these standards. For example:

• Section 508 mandates WCAG conformance for U.S. federal agencies.
• The EU Web Accessibility Directive covers public sector bodies across member states.
• The Accessible Canada Act extends requirements to federally regulated organizations.

Your hosting platform sits underneath all of this. It handles uptime, performance and deployment workflows. Accessibility compliance lives at the CMS and content layer.

What visitors need from an accessible site

Your templates and content choices determine WCAG compliance on the front-end.

Headings must follow a logical hierarchy without skipping levels. Images need alt text that communicates function in context, not decorative phrasing like "image of." Links need descriptive text because "click here" tells a screen reader user nothing about the destination.

Color contrast must meet WCAG 2.1 AA minimums: 4.5:1 for normal text and 3:1 for large text. Data tables require header cells and row associations so assistive technology can parse relationships between cells.

Content written at an eighth-grade reading level reaches more users, including people with cognitive disabilities and non-native speakers.

An accessible interface for content creators

ATAG Part A requires the CMS admin to be usable by people with disabilities:

Your editors may rely on screen readers, keyboard-only navigation, voice input or magnification software. If the editing interface traps focus in a modal or lacks label associations on form fields, those contributors can’t do their jobs.

WordPress targets WCAG 2.2 AA for its admin interface. Drupal treats accessibility bugs as release-blocking defects. These set a floor. Custom admin panels, third-party plugins and page builder interfaces often fall below it.

Evaluate your CMS admin the same way you evaluate your public site: tab through every workflow, check label associations and confirm status messages reach screen readers.

Testing before you publish

Automated scanners only catch roughly 20 to 30% of accessibility issues. Tools like WAVE and axe identify missing alt text, contrast failures and broken heading hierarchies.

They can’t evaluate whether alt text is meaningful or whether a custom widget is keyboard-operable.

Manual testing fills the gap: tab through each page, test with a screen reader like NVDA or VoiceOver and check that dynamic content updates are announced without a page refresh.

The strongest pattern is a publish gate inside your CMS workflow that blocks publishing when automated checks find failures.

Managed hosting platforms like Pantheon support Dev, Test, Live workflows where teams can run these checks in staging before content reaches the public site.

Where accessible CMS setups break down

Most accessibility failures come from layers added on top of the CMS core. Themes, plugins and architectural decisions can introduce gaps that no amount of platform-level commitment can prevent.

The "accessibility-ready" tag is the only tag in the WordPress repository that requires a mandatory manual audit by a specialized team before it can be used. However, outside the official repository, "accessibility-ready" theme labels are self-declared and loosely enforced. A theme can carry the label while shipping insufficient color contrast, missing skip navigation links or heading structures that break on specific page templates.

Audit the theme yourself before committing. Run automated scans and test keyboard navigation across every template, not just the homepage.

Plugins are the most common source of front-end accessibility regressions. A single carousel, modal or form plugin can introduce focus traps or controls that are invisible to screen readers.

Most plugin developers don’t prioritize accessibility. The burden of verifying each plugin falls on your team. When you update plugins, retest. Accessibility that worked in one version can break in the next.

Headless architectures shift accessibility responsibility entirely to the front-end. Your CMS becomes a content API and the presentation layer is yours to manage.

React components need proper ARIA roles and keyboard event handlers. Client-side routing must announce page changes to screen readers. Finally, JavaScript-loaded content that renders after the initial page load can be invisible to assistive technology unless your team implements live regions or focus management deliberately.

Site builders vs. open-source platforms

Site builders trade flexibility for tighter defaults. Squarespace and Webflow control the rendering layer. That means they can enforce accessible markup patterns across every site on their platform. They generate semantic HTML and handle focus management in built-in components without author intervention. The tradeoff is customization. When you need a component these platforms don’t offer, your options are limited. Workarounds often bypass the accessibility guardrails the platform provides.

Open-source platforms like WordPress and Drupal give you more control and more responsibility. The core CMS may meet accessibility standards, but your implementation choices determine the outcome.  WordPress powers over 40% of the internet. Its ecosystem of themes and plugins naturally varies wildly in accessibility quality. Your team must vet every addition.

Drupal has a stronger institutional stance. Accessibility bugs block releases. Its adoption in government and higher education reflects that commitment. But Drupal's flexibility still requires careful implementation at the theme and module level.

The deciding factor is whether your team has the governance appetite and technical capability to maintain accessibility over time.

Planning and budgeting for an accessible CMS

Accessibility work follows a sequence, and breaking it creates compounding debt. Choose the right platform and work outward through every layer your team controls:

• Choose a CMS with documented accessibility commitments and a track record of acting on them.
• Validate your theme or design system against WCAG 2.1 AA before building on top of it. Fixing templates after launch costs significantly more.
• Audit every plugin and module for keyboard operability, focus management and screen reader compatibility.
• Configure the CMS admin for accessibility: check that editorial workflows, media libraries and content editors meet ATAG Part A requirements.
• Train your editorial team on accessible authoring practices. Heading structure, alt text, link text and reading level are ongoing content decisions, not one-time fixes.
• Integrate pre-publication checks into your workflow so issues surface before content goes live.
• Set up ongoing monitoring. Accessibility degrades with every content update, plugin change and template revision.
• Allocate a dedicated budget for accessibility audits by qualified specialists. Keep hosting and accessibility separate, as managed platforms like Pantheon handle performance and uptime, not compliance.
• Budget separately for remediation development, editorial training and testing tools.

Key takeaways to create an accessible site

No CMS delivers compliance out of the box. Your platform sets constraints. Your team's design decisions and editorial governance determine whether the published site meets WCAG or fails it.

Evaluate platforms against both standards. WCAG governs what visitors experience. ATAG governs whether your authoring tool is accessible to contributors and whether it helps them produce accessible content. Most vendor comparisons only address one side.

The CMS core is rarely where accessibility falls short. Themes and plugins introduce the majority of failures. Architectural decisions like going headless shift that responsibility entirely to front-end teams that may not have accessibility expertise. Vet every layer you add and budget for the testing that requires.

Automated scanning catches a fraction of real issues. Manual testing with screen readers and keyboard navigation is where the substantive problems surface. Build publish gates into your CMS workflow so those checks happen before content goes live, not after a complaint.

Hosting and accessibility are separate budget lines. Pantheon's Dev, Test, Live workflows give teams staging environments to run accessibility checks before content reaches production.

Start building on Pantheon and ship faster with the workflow guardrails that accessibility governance requires.