Your CMS Can Be Compliant While Your Content Is Not

CMS vendors do genuine, meaningful work to make their platforms accessible. Drupal, Sitecore, SharePoint, and others invest real engineering effort into ensuring their navigation components, form templates, and interactive elements meet WCAG 2.1 AA requirements. When they tell you their platform is compliant, they're usually telling the truth — about the platform.

The problem is that "the platform is accessible" and "your content is accessible" are two separate statements. One is about the HTML scaffolding your CMS generates. The other is about every document, PDF, and piece of uploaded content that lives inside it. CMS testing almost never covers the second category.

What CMS accessibility testing actually covers

A CMS accessibility audit typically evaluates the parts of the system the vendor controls: page templates, navigation menus, search forms, error messages, modal dialogs, and interactive widgets. These are tested against WCAG criteria using automated tools and manual assistive technology testing. This is the right scope for a CMS vendor — it's their code, and they can fix it.

What it doesn't cover: anything uploaded by your organization. PDFs, Word documents, spreadsheets, presentations, images without alt text, embedded videos without captions. These go into the CMS as files; the CMS stores and serves them; the CMS vendor has no visibility into their internal structure. The document's tag tree, reading order, table headers, and form labels are determined at the time the document is created or remediated — not at the time it's uploaded.

A fully WCAG-compliant CMS will faithfully deliver an inaccessible PDF to every visitor who clicks a download link. The platform did its job. The document is still inaccessible.

Why this gap persists

The division of responsibility here is logical — CMS vendors can't be expected to remediate documents they didn't create. But it creates an accountability gap that organizations don't always notice until an accessibility audit surfaces it.

Most accessibility audits that organizations commission — whether through a consulting firm or an automated tool — focus on the web layer: HTML pages, interactive elements, media players. Documents are sometimes in scope, but they're often treated as a separate line item or deferred to a later phase. The result is that an organization can receive an "accessible website" certification while hosting hundreds of inaccessible PDFs, because the audit scope didn't reach the document library.

Under 28 CFR Part 35 — the DOJ's Title II implementing regulation for state and local governments — the obligation extends to all digital content, not just web pages. The fact that a document was created in another department, uploaded years ago, or originated from a third party doesn't change the organization's responsibility to ensure it's accessible. The CMS vendor's compliance status is relevant to the platform. It's not a proxy for the organization's overall accessibility posture.

Two audits, not one

The practical takeaway is straightforward: platform accessibility and content accessibility require separate assessments. Your CMS audit tells you whether the navigation, templates, and interactive components work for people using assistive technology. Your document audit tells you whether the files hosted on your site do the same.

Starting with a document inventory — even a rough one — is often more useful than organizations expect. Most find that their document library is much larger than anticipated, and that the concentration of issues is uneven: a small subset of document types (forms, reports with complex tables, multi-column layouts) accounts for the majority of failures.

Getting a clear picture of your document inventory doesn't require remediating everything immediately. Understanding the scope — how many documents, which types have the most issues, which are accessed most frequently — gives you the information to prioritize work that has the most impact on the people who use your content.

For a more detailed look at how these issues manifest in documents, the companion article Why Your CMS Being Accessible Doesn't Mean Your Content Is covers the underlying mechanisms in more depth.