CMS Implementation Services for Accessible Websites
"We build accessible websites" is a line nearly every agency uses, and it means wildly different things depending on who's saying it. For some, it means running a scanner before launch. For others, it means accessibility gets designed into the palette, the components, the content model and the authoring experience from day one.
Here's what an accessible CMS implementation should actually include, phase by phase, so you can compare proposals on substance rather than on the phrase "WCAG compliant."
Key Takeaways
- Accessibility work belongs in every phase of a build, not bolted on as a testing step at the end.
- The deliverables worth asking for: an accessible design system, structured content types, a proper component library, a constrained editor, author training and a written standard.
- Ask what happens after handover. Accessibility degrades through content, rarely through code.
- An independent audit is specialist work that complements building accessibly. It doesn't replace it.
- Compare proposals on named deliverables, not on a phrase that could mean almost anything.
Discovery and Requirements Come First
Accessibility requirements should be established here, not assumed later. That means confirming the standard and level you're working to, identifying obligations specific to your sector, understanding who your users are (including people using assistive technology), and auditing the current site so you know what you're inheriting.
This phase should also flag third-party dependencies: payment systems, booking engines, portals, video players, chat widgets. These are frequently the least accessible parts of a website, and whatever problems they have, you inherit.
What you should walk away with: a written accessibility requirement, and an inventory of third-party components with their accessibility status.
Then Comes the Design System
A surprising number of accessibility outcomes get locked in here, before a single line of code exists. That means checking colour combinations for contrast, designing visible focus states rather than leaving them to a developer, setting a type scale that survives being enlarged, specifying error and validation states in text rather than colour alone, and designing at multiple screen sizes.
What you should get: a design system with documented contrast ratios, defined focus and error states, and component specifications built with accessibility in mind from the outset.
The Phase Most Often Skipped: Content Modelling
This one has the biggest long-term effect and gets the least attention. Define content types with specific fields and the template generates correct semantic markup on its own, rather than depending on what an author does that day.
Deliverable: defined content types with field-level specifications, and a map of which template renders each one.
Building the Components
Interactive components get built once and reused everywhere. Each one needs correct keyboard interaction, managed focus, the right ARIA attributes, and testing with actual assistive technology. Navigation, accordions, tabs, modals, carousels, forms, date pickers, data displays: all of it.
You should end up with a component library, documented keyboard behaviour, and evidence it was tested with a keyboard and a screen reader, not just eyeballed.
Configuring the CMS Itself
This is where the authoring experience gets set up so the accessible option is the default one: required alt text with a decorative option, restricted heading levels, formatting controls removed where they create risk, pasted formatting stripped automatically, layout tables blocked, link text checked.
Ask to see it: a configured authoring experience, demonstrated by watching a non-technical person create a page.
Content Migration Is the Real Test
Migration is an opportunity, and skipping it is the usual outcome. Move content into structured fields and accessibility improves almost as a side effect. Bulk-import the old HTML instead and every old problem comes with it: missing alt text, broken heading structures, layout tables.
Documents deserve their own decision too. Important information trapped in an inaccessible PDF is usually better rebuilt as a web page than patched up as a file.
By the end: content migrated into structured fields, an alt text pass done on whatever images you kept, and a documented decision made on every document that matters.
Testing, Properly This Time
Automated scanning across every template, plus the manual testing a scanner simply can't do: keyboard-only navigation of every template and key journey, screen reader testing, zoom and text resizing checks, and a check that colour is never the only signal.
What matters isn't the report itself. It's one where the issues have been fixed, not just catalogued.
Training and Handover, Where It All Either Sticks or Doesn't
Accessibility degrades through content, which means handover is what decides whether any of the earlier work lasts. That should include training that explains why the constraints exist, a written authoring standard for your own setup, recorded sessions for whoever joins later, and a named owner with a real review cadence.
End state: trained authors, a written standard, recorded training, and a review schedule someone has agreed to.
How to Compare Proposals
Ask each agency which of these deliverables they include, and at which phase they do the accessibility work. A proposal that only mentions accessibility under testing is telling you something useful. So is one that can't explain how it stops content authors introducing new problems after launch.
Webcoda's been building websites from Sydney since 2005 and builds to the WCAG guidelines through design and development rather than as a final check. See our CMS implementation services and design services.
Frequently Asked Questions
It's worth doing before a major launch, or wherever you've got specific compliance exposure, and it's specialist work. Treat it as verification of a project that was built accessibly, not as the mechanism that gets you there. An audit at the end of a project that ignored accessibility just produces an expensive list of things to fix.
On its own, not a lot. It doesn't tell you which version, which level, whether the authoring experience was even considered, or whether anyone did manual testing. Ask for the specific version and level, and for the named deliverables sitting behind the claim.
Yes, and it's often worth doing in stages: fix the shared components first, since they affect every single page, then configure the editor to stop new problems appearing, then work through existing content in order of priority.
Whoever will publish content, someone with real authority over brand and design decisions, and ideally someone who uses assistive technology or can arrange testing with people who do. Content authors are the group most often left out, and the one whose absence causes the most damage.
Planned in from the start, it's largely absorbed into phases that already exist rather than tacked on as extra time, because it changes how the work gets done, not adds to it. The real schedule risk comes from discovering requirements late, after decisions are locked in.
Talk to Webcoda
Webcoda is a Sydney-based, B Corp certified digital agency building websites and enterprise web applications since 2005. Our education clients include UTS College, JMC Academy and The Anglican Schools Corporation, and we build accessibility into design and development rather than treating it as a final check. We are an Umbraco Gold Partner, a Gold partner for Xperience by Kentico and a HubSpot Solutions Partner.
Get in touch to talk through your project, or browse our services and platforms.
