Accessibility cannot be retrofitted at the end of a project.

Two families of requirements, two very different costs

The Web Content Accessibility Guidelines, in the 2.2 version published by the W3C, cover roughly sixty success criteria. From a project schedule's point of view they split into two families whose economics have nothing in common.

The first covers what can be corrected at almost any point: insufficient contrast, a missing alternative text, an ambiguous button label. These fixes are local, they call nothing into question, and a late audit handles them perfectly well.

The second depends on structural decisions: heading hierarchy, tab order, focus handling in modals, the name and role a custom control exposes, the relationship between a label and its field. Fixing those at the end does not mean adjusting a value. It means reopening components used everywhere, and sometimes rethinking how a page is assembled.

A late audit does not uncover defects. It uncovers decisions, taken months earlier by people who did not know they were taking them.

The three moments where accessibility is decided

In most projects three decisions determine the bulk of the outcome, and none of them has the word accessibility in its title.

The first is by far the highest-return. A form field built correctly once — associated label, announced error, visible focus — settles the question for the hundred screens that will use it. A faulty component reproduces its defect identically across the product, and the final audit will count it a hundred times.

The second is the most overlooked. If the content management tool lets an author fake a heading with bold text instead of a heading element, structure will erode regardless of how well the site was designed. The accessibility of a living site depends as much on what the editing tool makes easy as on what the code makes possible.

A legal picture that has tightened

Long treated as good practice, this has become an obligation in several jurisdictions. In Canada, the Accessible Canada Act covers federally regulated organizations and relies on a technical standard aligned with the European EN 301 549, which is itself built on the W3C guidelines. In Europe, the European Accessibility Act extends obligations to private-sector digital products and services.

For a Canadian organization, the practical consequence does not depend only on its own status. It depends on its customers: a public tender, an international partner or a large buyer will regularly require a conformance level and evidence to back it. At that point accessibility stops being a matter of intent and becomes a contractual artifact.

Building it in without inflating the project

The standard fear is a blanket cost increase. That fear is justified when accessibility is treated as an extra layer, and unfounded when it is folded into decisions the team is making anyway.

• Treat shared components as the primary conformance surface, and verify them once properly.
• Put two or three simple checks in the definition of done: keyboard navigation, visible focus, heading structure.
• Make the content model responsible for structure, rather than relying on author discipline.
• Run a human check early on one critical path, instead of a full audit at the end.

None of this requires scarce expertise. What it requires is moving the question a few months upstream, to the point where a decision still costs a conversation rather than a rebuild. That is the only window in which accessibility is economically unremarkable.