Accessibility Compliance in Application Modernisation Projects

If you're modernising a legacy application, build accessibility into the architecture decisions from day one — don't treat it as a post-launch fix. Audit the existing system against WCAG 2.2 before you lock in a target architecture, prioritise remediation using the same severity-and-effort lens you'd apply to any technical debt, and sequence the work against your chosen modernisation pattern so you fix each screen once, not twice. That's the short version. The rest of this guide covers why it matters, what the legal position actually is in Australia, how to audit a legacy system properly, and how to sequence remediation against a rebuild, re-platform, or strangler fig approach.

This guide is for engineering leaders who are scoping a modernisation roadmap and need to understand where WCAG 2.2 and the Australian Disability Discrimination Act fit alongside architecture decisions, technical debt paydown, and platform migration.

Why does accessibility matter in application modernisation?

Accessibility matters in application modernisation because legacy interfaces accumulate barriers that are expensive to fix in isolation but comparatively cheap to fix during a planned rebuild or re-platform. Addressing accessibility alongside architecture work means you change the underlying components once, rather than patching the same screen twice.

There's also a legal dimension. Under the Disability Discrimination Act 1992 (Cth), it is unlawful to discriminate against a person on the basis of disability in the provision of goods, services, or facilities — and the Australian Human Rights Commission has confirmed this extends to websites and digital services (humanrights.gov.au). Complaints under the DDA have led to real enforcement action against Australian organisations with inaccessible digital products, most notably the Maguire v SOCOG case concerning the 2000 Sydney Olympics website. Modernisation projects that ignore accessibility inherit this legal exposure rather than resolving it.

What are the legal obligations under the DDA and WCAG 2.2?

The Disability Discrimination Act does not prescribe a specific technical standard, but Australian courts and the Human Rights Commission consistently point to the Web Content Accessibility Guidelines (WCAG) as the relevant benchmark for what "accessible" means in practice. WCAG 2.2 is the current W3C standard, published in October 2023, defining testable success criteria across four principles: perceivable, operable, understandable, and robust.

Australian government digital services are generally required to meet WCAG 2.2 Level AA under the Digital Service Standard, and this level is the de facto benchmark private sector organisations are measured against when a DDA complaint is lodged. WCAG 2.2 added new success criteria beyond WCAG 2.1, including requirements around focus visibility, target size for touch interfaces, and reducing reliance on dragging gestures — all directly relevant to teams modernising mobile and web front ends.

It's worth noting there is no formal Australian legal mandate that private sector companies meet a specific WCAG level. The obligation is the broader DDA prohibition on discrimination; WCAG conformance is the practical evidence base used to demonstrate — or dispute — compliance. Treat WCAG 2.2 AA as the target, not because the law names it directly, but because it is the standard regulators, courts, and plaintiffs' advisors will reference.

How do you audit a legacy system for accessibility gaps?

An accessibility audit for a legacy system should combine automated scanning, manual testing with assistive technology, and a code-level review of how the application was built — because automated tools alone catch a subset of real-world barriers, not the full picture. Start before you touch the architecture, not after.

A practical audit sequence for a modernisation project looks like this:

1. Automated scan across key user journeys. Tools that check against WCAG success criteria will surface structural issues — missing alt text, poor colour contrast, missing form labels — quickly and cheaply, but they typically only detect a subset of all WCAG failures.
2. Manual keyboard-only testing. Many legacy single-page applications and custom UI components were never built to be operable without a mouse. This is one of the most common and most disruptive gaps to remediate late.
3. Screen reader testing using tools like NVDA or VoiceOver across critical flows — login, checkout, form submission, search.
4. Code-level review of the component architecture. Determine whether accessibility issues are isolated to markup (fixable with templates) or baked into the underlying framework or custom component library — this affects your modernisation architecture decisions directly.
5. Document findings against WCAG 2.2 success criteria, not just as a general list of bugs, so remediation work can be prioritised and tracked against a recognised standard.

This audit should happen in parallel with — or just ahead of — the technical architecture review that typically kicks off a modernisation engagement. Our application modernisation work often starts exactly this way: assess the current state of the system, including accessibility debt, before committing to a target architecture.

How should accessibility remediation be prioritised alongside architecture work?

Accessibility remediation should be prioritised using the same severity-and-effort lens you'd apply to any technical debt, but sequenced against your chosen modernisation pattern so you're not fixing the same screen under two different architectures. The right sequencing depends heavily on whether you're rebuilding, re-platforming, or incrementally strangling the legacy system.

If you're doing a full rebuild, build to WCAG 2.2 AA from day one inside your design system and shared component library. This is the lowest-rework path because every screen inherits accessible primitives automatically — buttons, forms, navigation, and focus management only need to be solved once.

If you're re-platforming an existing front end onto new infrastructure without a full UI rewrite, remediate the component library before or during the migration rather than after. Re-platforming without touching accessibility debt simply moves the same barriers onto new infrastructure, and you'll end up repeating the fix later.

If you're using a strangler fig pattern — incrementally replacing legacy modules behind a routing layer — treat each strangled module as an opportunity to bring that slice up to WCAG 2.2 AA as part of the cutover, rather than batching accessibility into a separate workstream. This keeps remediation scoped to work you're already doing, and avoids a second pass through modules you've already touched. We've written more on this pattern in our piece on the strangler fig pattern for legacy systems.

In all three cases, the principle is the same: accessibility debt compounds the same way technical debt does, and a modernisation project is the cheapest point in the system's lifecycle to resolve it. Treat it as a first-class input to your architecture review, not a QA checklist applied at the end.

Accessibility work rarely stays isolated to the front end. If your modernisation roadmap includes rethinking product direction or embedding AI-assisted features, it's worth considering accessibility alongside ai product strategy and ai engineering decisions early, since conversational interfaces, generated content, and AI-assisted workflows introduce their own accessibility considerations that are easier to design in than retrofit.

If you're scoping a modernisation roadmap and want a second opinion on where accessibility debt sits relative to your architecture decisions, get in touch — we're happy to talk through what a staged audit and remediation plan could look like for your system. You can also browse more insights on modernisation, data infrastructure, and AI adoption from our team.