Accessibility is a default, not a phase

Most projects I'm brought into have accessibility on the plan. It's usually near the bottom. "Accessibility audit," sometime after the build, just before launch. By then most of the budget is spent and the date is close. So the audit becomes a list of tickets, and the tickets become a backlog.

I don't work that way. WCAG 2.2 AA is the default on every screen I touch. It isn't an add-on or a line item you can drop. Here's what that looks like, and why it costs less.

Who it's for

A blind researcher is a researcher. That was the reason for the Section 508 testing and accessibility audits I did across NASA's Earthdata sites, and it holds everywhere. A screen-reader user booking a class is a customer. A provider who uses a keyboard instead of a mouse is a provider. Someone squinting at a phone in bright sun needs readable contrast as much as anyone.

Most of the people who can't use your site won't tell you. They just leave.

Check it at the wireframe

The first check happens in low fidelity, before anything looks finished. My wireframes use real content, real labels and real error states, never placeholder text. You can't tell whether a form label makes sense if it says "Lorem ipsum."

At the wireframe I'm asking plain questions. Does every field have a label a screen reader can announce? Does the order on the page match the order someone would tab through it? Is anything said only with color? When something goes wrong, does the page say what and where?

That last one is where most forms fail. On the Child Action provider portal, which Sacramento County childcare providers use to keep their licenses current, I designed the error states before the happy path was finished. When an email address is malformed, the message says "Email address requires @ symbol," not "invalid input." When a provider tries to register for a workshop without the prerequisites, the message names the missing documents and links to the page where they upload them. That's good accessibility. It's also good manners.

Write the test before the thing exists

The same portal had an eligibility checker that opened in a dialog. Dialogs are where keyboard users get stuck. So before it was built, I wrote the test plan:

• every control reachable with Tab and Shift+Tab
• no keyboard trap, inside or outside the dialog
• Space toggles, Enter activates, Escape closes and puts focus back where it was
• the dialog announced by name
• table headers read correctly
• changes announced as selections change
• focus always visible
• status never shown by color alone

It cost an afternoon, for a component that didn't exist yet. On a portal whose users include providers working with disabled children, that's the minimum, not the extra.

Check it again in code

A design that passes on paper can still fail in the browser. The heading order shifts. A custom dropdown swallows the arrow keys. Focus disappears after a pop-up closes.

So the second check happens in code, and a person does it. Every change I ship is run on a real device with a screen reader before it goes in. Automated scanners help, and they're fast. But a tool's pass is a start, not a sign-off. A scanner can tell you a button has a name. It can't tell you whether that name makes sense read aloud.

This is one reason I write the front-end myself on most projects. The person who decided how the dialog should behave is the person checking that it does.

Why retrofitting costs more

Accessibility added at the end isn't one fix. It's many small ones, scattered through work that's already done and already approved.

A missing label is quick. But a form that only makes sense visually has to be restructured. A dialog that traps focus has to be rebuilt. A color palette that fails contrast sends you back to visual design, back for approval, and then through every screen. Each fix reopens something people thought was finished. That's where the cost comes from. Not the fix itself, but the rework around it.

There's a quieter cost too. Some things never happen at all unless someone raises them early. On a site for Inglis, a disability-services organization, the footer carries an accessibility statement and a direct line for anyone having trouble with assistive technology. Another team did the build. That detail made it to the live site because it was argued for early, in the journey work. If it had first come up at launch, it would have been a ticket.

It's in the small work too

This isn't only for big projects. A UX review from me includes an accessibility spot check against WCAG 2.2 AA. Wireframes get checked before they leave my hands. Visual design comes with contrast checked. A front-end build from your designs is tested with a screen reader and on real phones. Website care includes a monthly accessibility check alongside the speed check.

None of it is an extra fee for doing the right thing. It's how the work gets done.

A plain way to start

If you want to know where your site stands, try three things this week. Put your mouse away and use your site with only the keyboard. Turn on the screen reader built into your phone and try your most important form. Read your error messages out loud and ask whether they tell someone what to do next.

If any of that goes badly, you've found your starting point.

If that sounds like your situation, let's talk.