A CMS accessibility audit evaluates the system that produces your website, including templates, components, editor workflows, and configurations, to ensure accessibility is built into the redesign from the start.
A website redesign is one of the highest-value moments in a public agency's digital lifecycle. New templates. New components. New content structure. New vendor integrations. Done right, a redesign is the single best opportunity to build accessibility in from the start rather than bolt it on after the fact.
Done wrong — which is how most government redesigns handle accessibility — it is an expensive way to inherit a new set of problems on top of the old ones.
Here is the pattern that plays out constantly. An agency commissions a redesign. The scope includes "accessibility compliance." The development team builds to WCAG 2.1 AA. An audit is run before launch, issues are found, some are fixed, the site launches. Six months later the compliance posture has regressed because the CMS publishing environment was never configured for accessibility, editors were never trained, vendor integrations were never tested, and the governance handoff that would have sustained the work never happened.
The redesign produced a compliant website on launch day. It did not produce a compliant program.
This guide is about how to prevent that. It covers what a CMS accessibility audit before a redesign should evaluate, what questions to ask your development team, what governance handoffs need to happen before the project closes, and how Hounder approaches accessibility in government redesign engagements so that compliance is built into the foundation rather than reviewed at the finish line.
Why "We'll Check It Before Launch" Is Not a Strategy
The instinct to treat accessibility as a pre-launch QA activity is understandable. It feels like the logical time to check. The site is built. You can see it. You can test it.
The problem is that by the time a redesign reaches pre-launch QA, the decisions that determine accessibility have already been made. Template architecture. Component library choices. CMS configuration. Text format settings. Editor interface design. Vendor integrations. Navigation patterns. Form frameworks. All of these structural decisions are baked in. Fixing accessibility at that stage means rework — which costs significantly more than building correctly the first time.
The research on this is consistent and applies directly to web development: defects found and fixed during design cost a fraction of defects found and fixed after development. Accessibility issues found before a template is built are configuration decisions. Accessibility issues found after a site launches are remediation projects.
The CMS accessibility audit that happens before a redesign begins is the document that prevents the expensive rework. It identifies what the current environment's accessibility failures are, what the new environment must be configured to prevent, what components need to be built to a specific standard, and what governance structures need to exist before the project closes for the compliance posture to survive contact with actual content editors.
What a CMS Accessibility Audit Covers Before a Website Redesign
A CMS accessibility audit before a redesign is not the same as a website accessibility audit. It is evaluating the system that produces the website, not just the website itself. The scope is different. The questions are different. The outputs are different.
1. Current Template and Component Audit
Before designing new templates, document exactly where the current templates fail. This is the baseline that informs what "better" looks like for the new build.
The current template audit should identify:
Global component failures. Navigation structure, skip link implementation, focus indicator visibility, landmark region definitions, header hierarchy in shared layouts. These are the issues that affect every page and that need to be addressed at the template level in the new build.
Form component failures. Label association patterns, error handling implementation, required field indication, focus management in multi-step flows. Government sites rely heavily on forms. If the form component library is not built accessibly, every form on the new site inherits those failures.
Media component failures. How the current CMS handles image alt text — is it required, optional, or absent from the interface? How does it handle video embeds — does the template support caption integration? How does it handle document downloads — does it surface accessibility requirements at the upload point?
Interactive component failures. Modal dialogs, accordion panels, tab interfaces, dropdown menus, date pickers. Every interactive component in the new design needs to be evaluated against WCAG keyboard operability and screen reader compatibility requirements before it is built.
Color and contrast implementation. Is the current design system's color palette WCAG 2.1 AA compliant? Which color combinations fail? This audit informs the brand and design decisions that need to happen in the design phase of the redesign before any code is written.
2. CMS Configuration Accessibility Audit
The CMS configuration determines what editors can do, what they cannot do, and what happens by default. Most CMS accessibility failures are not code failures — they are configuration failures that allow editors to create inaccessible content without any guardrail.
Text format configuration. Drupal, WordPress, and most government CMS platforms allow administrators to configure which HTML elements are permitted in the body editor. If the text format allows editors to use heading elements, is the heading hierarchy enforced or can editors apply H1 inside body content? If the text format allows tables, does it require caption elements? If it allows links, does it prevent empty link text?
Image field configuration. Is the alt text field on image uploads required or optional? Is there guidance in the interface about what constitutes meaningful alt text? Is there a mechanism to mark images as decorative? Most CMS platforms default to making alt text optional — which is the wrong default for a compliant publishing environment.
WYSIWYG editor configuration. The editor toolbar configuration determines what options editors have and what defaults are applied. Is the heading selector showing semantic heading levels or visual size options? Are accessibility-related functions available — list formatting, table headers, link text — or buried?
Media library configuration. When editors upload documents, is there any accessibility check or guidance at the point of upload? Most government CMS environments have no mechanism to prevent an editor from uploading a scanned PDF and publishing it with a single click.
User role permissions. What can different user roles do in the CMS? Can department editors modify template markup? Can they install plugins or widgets? Accessibility governance requires that the permissions structure prevents editors from breaking accessibility at the template level.
3. Content Editor Interface Audit
The content editing experience shapes what editors produce. If the editor interface is confusing, poorly labeled, or structured in a way that makes accessible content creation harder than inaccessible content creation, editors will produce inaccessible content. Not because they are negligent — because the interface defaulted them there.
Evaluate the current editor interface for:
Alt text prompting. When an editor inserts an image, does the interface prompt them to add alt text before they can continue? Is there guidance in the prompt about what good alt text looks like?
Heading guidance. When an editor uses the heading selector, is it labeled by semantic level (Heading 2, Heading 3) or by visual appearance (Large, Medium)? Semantic labels produce semantic choices. Visual labels produce visual choices that may or may not carry structural meaning.
Link text guidance. When an editor creates a link, is there any mechanism that flags potentially inaccessible link text — "click here," "read more," "learn more" — or is it entirely the editor's responsibility to write descriptive link text?
Table creation guidance. When an editor creates a table, does the interface prompt them to designate a header row? Most CMS editors do not.
Document upload guidance. When an editor uploads a PDF or Word document, is there any accessibility check, guidance, or checklist presented at the point of upload?
4. Third-Party Accessibility Audit for CMS Integrations
A redesign is often the moment when new vendor integrations are added or existing ones are updated. The accessibility of embedded third-party tools is the most commonly missed scope item in government redesign projects.
Before the redesign begins, inventory every third-party tool that will be integrated into the new site:
- Payment processing platforms
- Permit and license portals
- Online scheduling systems
- GIS and mapping tools
- Chat and support widgets
- Form builders and survey tools
- Video platforms and players
- Social media embeds
- Search tools
For each tool, request a current VPAT and evaluate it against WCAG 2.1 AA criteria. Identify which tools have known conformance gaps. Determine whether those gaps can be remediated through configuration, whether the vendor has a roadmap for addressing them, or whether an accessible alternative pathway needs to be built alongside the embedded tool.
This inventory happens before the redesign scope is finalized — not after the integrations are built — so that vendor accessibility requirements can be written into contracts and accessible alternative pathways can be scoped as design requirements rather than post-launch patches.
5. Accessibility Governance and Training Audit Before Redesign
The last thing a CMS audit before a redesign evaluates is the governance environment the new site will be published into. This is the piece most redesign audits skip entirely. It is also the piece that determines whether the compliant site that launches stays compliant six months later.
Content governance assessment. Who publishes content to the current site? How many editors are there across how many departments? What is their current level of accessibility awareness? Do any accessible content standards exist and are editors aware of them?
Training gap assessment. What accessibility training, if any, have current editors received? What role-specific training will editors need before they publish content on the new platform? Is that training budgeted and scoped as part of the redesign project?
Document workflow assessment. What is the current process for creating and publishing documents? Who creates PDFs? What tools do they use? Is there any pre-publication accessibility review? What standards will govern document creation on the new platform?
Ownership and accountability assessment. Who will own accessibility on the new platform? Is that role defined and staffed? Is there a monitoring program planned for after launch? Is there a remediation log planned? Is there an executive reporting cadence defined?
If the answers to these questions are unclear or unfavorable, they are design constraints for the governance framework that needs to be built as part of the redesign project — not problems to solve after launch.
What to Ask Your Development Team Before the Redesign Begins
If you are working with a development partner on a government website redesign, these are the specific questions that determine whether accessibility is being built into the foundation or checked at the finish line.
How are you approaching accessibility in the component library? The answer should describe a development process where every component is built to WCAG 2.1 AA from the start, tested with keyboard navigation and screen reader software during development, and validated before it is added to the library. If the answer describes an accessibility review at the end of development, that is pre-launch QA — not accessible development.
How will the CMS be configured to support accessible content creation? The answer should describe specific configuration decisions: required alt text fields, semantic heading selectors, accessible table creation workflows, document upload guidance. If the answer is "we'll build the theme to be accessible," that is a website answer, not a CMS answer.
What is the plan for editor training before launch? The answer should include a specific training plan, role-specific content, and a documented completion standard. If there is no training plan in the project scope, accessible content will not be produced consistently after launch.
What accessibility testing will happen during development — not just before launch? The answer should describe testing integrated into the development workflow: keyboard testing during component build, screen reader testing before component sign-off, automated scanning during the build process. If the only testing described happens at the end, late-stage fixes are the plan.
What governance framework will be in place at launch? The answer should describe a remediation log, a monitoring program, an accessible content publishing standard, and defined ownership. If the project scope ends at launch without a governance handoff, the compliance posture will begin degrading immediately.
The Hounder Approach to Accessibility in Government Redesigns
At Hounder, accessibility is not a phase in our redesign process. It is the framework the process runs inside.
That means the CMS accessibility audit happens before discovery is complete, not before launch. Template accessibility requirements are defined before design begins, not reviewed after development ends. Component accessibility is validated during build, not patched after QA. Editor training is planned as part of project scope, not assumed to happen informally. The governance handoff — remediation log, monitoring program, publishing standards, ownership definitions — is a project deliverable, not an afterthought.
The reason for this is practical. Governments do not have the budget to fix accessible builds that regress because the governance did not survive the project. The work we do in a redesign needs to hold. That requires treating accessibility as an operational foundation rather than a compliance deliverable.
For agencies that have been through a redesign that did not produce a durable compliance posture, the post-redesign governance assessment is the starting point. We establish the baseline that the redesign should have established, build the governance structures that should have been part of the project scope, and create the monitoring and documentation program that sustains the compliance the redesign was supposed to produce.
The Pre-Redesign CMS Accessibility Audit Checklist
Use this as a starting framework for evaluating your CMS before a redesign begins.
Current Template Audit
- Global navigation accessibility evaluated (keyboard, focus, landmarks)
- Form component failures documented
- Interactive component failures documented (modals, accordions, tabs, dropdowns)
- Color contrast compliance evaluated across the design system
- Skip link implementation evaluated
- Heading hierarchy in shared layouts evaluated
CMS Configuration Audit
- Text format HTML allowlist reviewed for accessibility implications
- Alt text field evaluated (required vs. optional, guidance present)
- WYSIWYG toolbar configuration evaluated
- Table creation workflow evaluated (header row support)
- Document upload workflow evaluated (accessibility guidance at upload)
- User role permissions reviewed for template modification risks
Content Editor Interface Audit
- Alt text prompting evaluated at image insertion point
- Heading selector labels evaluated (semantic vs. visual)
- Link text guidance evaluated
- Table header designation evaluated
- Document upload accessibility guidance evaluated
Third-Party Integration Audit
- Full inventory of embedded tools completed
- VPAT requested and reviewed for each tool
- Conformance gaps documented
- Accessible alternative pathways identified for gap areas
- Vendor accessibility requirements drafted for contract inclusion
Governance Gap Audit
- Editor count and accessibility awareness level documented
- Training gaps identified and training plan drafted
- Document workflow and creation standards documented
- Post-launch ownership defined
- Monitoring program planned
- Remediation log structure designed
- Executive reporting cadence defined
Related:
Good Faith Compliance Explained
FAQ: CMS Accessibility Audits Before Website Redesigns
Why should a CMS accessibility audit happen before a redesign rather than at the end?
Accessibility decisions made during the design and build phase of a redesign — template architecture, component library choices, CMS configuration, editor interface design — are far less expensive to get right than to fix after the fact. A pre-redesign audit identifies the current environment's failures, defines the requirements the new build must meet, and ensures that accessibility is a design constraint rather than a post-launch patch. Accessibility issues found before a template is built are configuration decisions. Accessibility issues found after launch are remediation projects that cost significantly more.
What is the difference between a website accessibility audit and a CMS accessibility audit?
A website accessibility audit evaluates the accessibility of the content and interface that users experience. A CMS accessibility audit evaluates the system that produces that content — the template architecture, the editor interface, the configuration that determines what editors can do, and the governance environment that shapes what they actually produce. Both are necessary. For a redesign, the CMS audit is the more valuable starting point because it informs the design requirements that prevent failures from being built into the foundation.
Should third-party vendor tools be included in a pre-redesign accessibility audit?
Yes. Third-party integrations are one of the most commonly missed items in government redesign accessibility scopes. Payment portals, permit systems, mapping tools, scheduling platforms, and other embedded tools carry the same ADA Title II compliance obligation as the primary website. Before a redesign finalizes its integration scope, every vendor tool should have a VPAT reviewed, known gaps should be documented, and accessible alternative pathways should be designed for areas where vendor tools cannot meet WCAG 2.1 AA requirements.
What governance deliverables should be part of a government website redesign?
A government website redesign that does not include governance deliverables will produce a compliant site on launch day that regresses within months. The governance deliverables that should be part of every government redesign project scope include: role-specific editor training with documented completion, accessible content publishing standards distributed to all editors, a remediation log structure established and active at launch, a monitoring program planned with a defined cadence, defined ownership of post-launch accessibility at both the operational and executive level, and a vendor review process for any integrations added after launch.
How does Hounder approach accessibility in government website redesign projects?
Hounder treats accessibility as the operational framework the redesign process runs inside rather than a phase or a deliverable. That means the CMS audit happens before discovery is complete, template requirements are defined before design begins, component accessibility is validated during build, editor training is scoped as a project deliverable, and the governance handoff — monitoring program, remediation log, publishing standards, ownership definitions — is a required project output. The goal is a redesign that produces not just a compliant website but a compliant program that holds up over time.