Accessibility Is a Requirement, Not an Audit

The standard sequence is that a product is designed, built, and then audited for accessibility shortly before it ships. The audit returns a list. Some of the list is quick — missing labels, contrast, focus styles. The rest traces back to decisions made in the first fortnight, and by then nobody wants to reopen them.

So those items become a backlog, the backlog becomes a roadmap item, and the roadmap item does not survive its first collision with a launch date.

None of this is because teams do not care. It is because the work was scheduled at the point where it is most expensive.

Most of it is not extra work

A large share of accessibility is simply doing the ordinary thing correctly.

Using a button element for something that behaves like a button gets keyboard operation, focus handling and screen reader semantics without any additional effort. Building the same control from a styled div means reimplementing all of it by hand, usually incompletely. The accessible version is less code.

Form inputs with real labels, headings that describe structure rather than being chosen for their font size, images with alternative text written when the image is placed — each of these costs almost nothing at the time and is tedious to retrofit across a finished application.

The expensive findings in most audits are not exotic. They are ordinary markup decisions made without the semantics in mind.

Keyboard operation is the fastest useful test

Before any tooling, put the mouse down and try to complete the primary task using only the keyboard.

This surfaces more real problems, faster, than any automated scan: focus that vanishes, modals that do not trap focus and let you tab into the page behind, custom dropdowns that cannot be opened at all, focus indicators removed for aesthetic reasons, and interactive elements skipped entirely in the tab order.

It takes a few minutes per flow and requires no specialist knowledge. It is the highest-yield accessibility activity available to a team that is not doing any.

Automated tools find perhaps a third

Automated checks are worth running in the pipeline and worth being honest about. They reliably catch contrast, missing alternative text, missing labels and some ARIA misuse. They cannot tell whether alternative text is meaningful, whether the reading order makes sense, whether a custom component behaves the way a screen reader user expects, or whether an error message is announced.

A clean automated report means the mechanical problems are handled. It says very little about whether the product is usable.

Contrast is a design decision

Colour contrast is the finding that most often arrives too late to fix cleanly, because by then it is not one screen — it is the palette, applied across an entire product, sometimes across a brand.

Checking contrast ratios while the palette is being chosen costs an afternoon. Discovering afterwards that the brand's primary colour fails against white for body text is a much larger conversation, and it is one that tends to be resolved in favour of the brand.

Light grey text on white is the most common instance, and it is worth saying plainly: it is not more elegant. It is less readable for everyone, and unreadable for some.

The commercial argument, since it usually helps

Public sector and enterprise procurement increasingly requires conformance statements, and a product that cannot produce one is excluded from the tender regardless of its merits. In several jurisdictions there is legal exposure attached.

None of that is the reason to do it. It is, however, the reason it tends to get scheduled — and if that is what moves it from the backlog into the requirements, the outcome is the same.

Where it belongs

In the definition of done, alongside the tests. A component is not finished because it looks right; it is finished when it is operable by keyboard, labelled, announced correctly and legible.

Held there, accessibility stops being a project. It becomes a property of how the team builds, and the audit before launch turns into a confirmation rather than a discovery.

---

iLeaf builds interfaces to this standard as a default rather than an upgrade — see How we work.