How CMS Implementation Improves Accessibility

Sasha Shevelev 14 August 2026

User Experience Web Development CMS

Organisations often treat accessibility as a testing problem. Build the site, run a scan, fix whatever it flags. That sequence explains why so many sites pass an audit and still fail their users, and why "fixed" sites tend to drift back out of compliance within a year.

Accessibility is better understood as an outcome, not a checkpoint. It falls out of decisions made during implementation, long before anyone runs a scanner. Here's how that plays out, and what to ask a supplier to show you.

Key Takeaways

Accessibility that depends on people remembering the rules will degrade. Built into templates and fields, it tends to stick.
Structured content produces correct markup automatically, removing whole categories of error.
A shared component library fixes keyboard behaviour and focus management once, instead of page by page.
WCAG 2.2 Level AA is now the reference point for Australian Government digital services and Digital NSW. Establish which version you're quoted against.
Scanners catch a minority of real issues. Keyboard and screen reader testing still happens by hand.

Structured Content Beats Free Text

This is the biggest lever, and the one people talk about least. When a page is built from defined fields rather than one rich text box, the markup comes from the template, not whoever is typing.

An author entering a job title into a "position" field can't turn it into a heading level five, or bold text a screen reader announces as prose. Every profile gets correct heading structure because a developer decided it once. Each content type defined this way, course, service, location, event, person, policy, removes a recurring error for good.

Guardrails in the Authoring Experience

Where free text genuinely is needed, the editor should make the accessible choice the path of least resistance:

Alt text as a required field, with an explicit option to mark an image decorative.
Only valid heading levels on offer, so nobody jumps from H2 straight to H5.
Font colour and size controls removed, so contrast can't be broken by accident.
Formatting stripped automatically when content is pasted from Word or Google Docs.
Layout tables blocked, with a proper layout component provided instead.
Link text checked, so "click here" gets flagged rather than published.

None of this is exotic. Every item is a configuration decision, cheap during implementation and awkward to retrofit later.

Build the Components Once, Properly

Interactive components are where accessibility usually falls apart: navigation menus, accordions, tabs, carousels, modals, forms. Each needs correct keyboard behaviour, sensible focus management and the right ARIA attributes. Build them as a reusable library and every page inherits the same behaviour. Build them ad hoc and you guarantee inconsistency.

The argument sharpens with more authors. Webcoda's platform for The Anglican Schools Corporation runs 17 schools from one SharePoint build, using custom reusable web parts and more than 10 page templates. That was an intranet project, not an accessibility engagement, and it's here to illustrate the governance problem rather than as an accessibility credential. When authors across 17 sites assemble pages from the same components, whatever those components do is what every school gets. Fix it once, or fix it 17 times and miss some.

Some Decisions Happen Before Anyone Writes Code

Colour palettes either meet contrast requirements or they don't. Type scales either stay readable when text is enlarged or they don't. Focus states either exist in the design, or a developer invents something at the last minute. Checking contrast at the palette stage takes minutes; discovering after launch that a brand colour fails against white, and that it's on every button, is a much bigger conversation.

Scanners Only Catch Part of the Picture

Automated tools are useful and worth running continuously, but they only evaluate what a machine checks mechanically. They can't tell you whether alt text is meaningful, whether link text makes sense out of context, or whether an error message tells someone how to fix the problem. So implementation needs keyboard-only navigation through every template, screen reader testing of the key journeys, and a check that nothing depends on colour alone.

Which Standard, and Who It Binds

Ask which version of WCAG you're quoted against, because the answer has moved. WCAG 2.2 became a W3C Recommendation in October 2023 and is now published as ISO/IEC 40500:2025. The Commonwealth Digital Service Standard v2.0 no longer names a version, requiring the latest instead, and Digital NSW points at 2.2 Level AA. Older policy documents and live contracts still say 2.1 Level AA, so get it stated explicitly.

Two things beyond the guidelines. Since 1 July 2024 the Digital Service Standard applies to new and replacement staff-facing services, so a new government intranet sits inside mandatory scope. And under the Disability Discrimination Act 1992 the obligation belongs to the organisation providing the service; a supplier contract doesn't transfer that duty.

Why the Order Matters

Every mechanism above is cheap while a site is being built and expensive afterwards. Changing a colour palette during design costs nothing; after launch it means revisiting every component that uses it. Making alt text required is a five-minute change during implementation. Adding it to five thousand existing images is its own project.

Webcoda builds to the WCAG guidelines through design and development rather than testing at the end, and treats the authoring experience as part of that scope. To be straight about it: we don't sell accessibility audits as a product, and we don't publish a certified conformance level for our work. What we can show you is the implementation practice, in our CMS implementation and web development work. If an agency offers a guaranteed conformance level on a site authors keep editing, ask how they intend to hold it.

Frequently Asked Questions

WCAG 2.2 Level AA is the current reference point. It's a W3C Recommendation from October 2023, published as ISO/IEC 40500:2025, and it's what the Commonwealth Digital Service Standard v2.0 and Digital NSW effectively point at. Older documents and existing contracts often still cite 2.1 Level AA, so confirm the version in writing before work starts.

Rarely on its own. Platform choice has some effect, particularly on how configurable the editor is and whether the admin interface itself is accessible, but implementation decisions matter far more. Different agencies building on the same platform still land in very different places.

No, and we'd rather say so than dress something up. Webcoda builds to the WCAG guidelines through design and development, and doesn't sell accessibility audits as a separate product or publish a certified conformance level. What's demonstrable is the implementation practice: structured content types, constrained authoring, and shared component libraries like the reusable web parts behind the 17-school Anglican Schools Corporation platform. Ask any agency to walk you through their authoring guardrails rather than to show you a certificate.

For Australian Government services, yes, for new and replacement staff-facing services since 1 July 2024 under the Digital Service Standard. Only existing staff-facing services sit outside it. Beyond government, the Disability Discrimination Act 1992 applies to the organisation providing the service, and your staff include people with disability too.

Less than most people assume, if it's planned in from the start, because it's mostly doing the same work correctly rather than doing additional work. The expensive version is remediation after launch, which drags you back into design, templates and existing content all at once.

Reduce how much depends on people remembering things. Guardrails in the CMS, structured content types, a named owner, accessibility in author induction and a periodic review together do far more than a single training session.

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.