Accessibility is not a checkbox at the end of a project

Accessibility usually enters a project in one of two ways. Either it is considered during design, or it arrives as an audit two weeks before launch with a list of forty issues and no budget to fix them. The second route costs more and produces a worse result.

Who this is actually for

It is easy to treat accessibility as an abstract compliance requirement. It is more useful to be concrete: someone with low vision using a screen magnifier, someone who cannot use a mouse, someone with a tremor trying to hit a small button, someone on a train reading in bright sunlight.

For a hospital or a government agency this matters more than anywhere else, because the people most likely to have accessibility needs are frequently the people with no alternative route to the service.

What WCAG AA means in practice

• Text meets minimum contrast against its background — 4.5:1 for body text
• Every interactive element is reachable and visible using only a keyboard
• Form fields have real labels, not just placeholder text
• Content survives being zoomed to 200% without breaking
• Nothing is communicated by colour alone
• Images have alt text that describes their purpose, not their appearance

Why the timing matters

Most accessibility failures are decisions, not bugs. Light grey text on white is a colour choice. A form that only validates on submit is an interaction choice. Changing those after build means revisiting design, development, and testing — three times the work of getting it right in the first place.

The cheapest accessible website is the one that was designed to be accessible. Everything else is rework.

A test you can run right now

Put your mouse away. Using only the Tab key, try to navigate your homepage and complete your main contact form. If you lose track of where the focus is, or you reach something you cannot activate, you have found a real problem that a real person is hitting today.