is an accessibility audit out of scope?

The baseline is; formal conformance isn't, and the whole confusion lives in collapsing the two. Building properly does include a real floor of accessibility — semantic HTML, alt text, keyboard-usable controls, decent contrast — and you should deliver that as a matter of craft, not bill it as a premium. But there's a large gap between 'reasonably accessible because I build competently' and 'verified compliant with WCAG AA across every success criterion, tested with screen readers, documented in a conformance report.' The second is an audit-and-remediation discipline with its own techniques, tools, and edge cases — managing focus in complex widgets, getting ARIA exactly right, systematically auditing contrast, handling dynamic content for assistive tech. That work scales with the site and the target level, and it's a specialism people build careers around. So yes, basic accessibility is part of building properly; no, formal compliance certification is not automatically included, any more than 'building a house properly' includes a full structural engineering inspection.

You're on the hook for the baseline a competent build includes, not for a formal standard nobody named. If 'accessible' to the client means the reasonable floor — it works with a keyboard, images have alt text, the markup is semantic — then delivering that is just doing the job, and you should. But if 'accessible' turns out to mean 'conformant with WCAG AA and documented,' that's a specific, demanding standard that should have been scoped, and an unspoken assumption doesn't silently expand your contract to include an audit. The fair move is to clarify which they mean before it turns adversarial: 'The build includes solid baseline accessibility as standard — if you need formal WCAG conformance with testing and a report, that's a specialized piece I'd scope separately.' Often the client just wants the baseline and is reassured to learn it's already there. When they genuinely need certified compliance, naming it as separate work isn't dodging — it's matching the price to a real, specialized job.

Then surface it immediately and treat it as a real constraint rather than a negotiating point, because a legal accessibility obligation changes the conversation. Public sector bodies, large enterprises, and organizations in certain jurisdictions can be legally required to meet a conformance level, and a client in that position usually has both a hard requirement and budget allocated for it — they may simply have assumed you knew. So the worst response is to litigate whether it's in scope; the right one is to clarify the requirement fast and scope to meet it properly. Be honest about your own capacity: certified compliance carries legal weight, and half-doing it exposes the client to risk and you to liability. If it's within your skill set, quote it as the serious engagement it is, with a defined target level and testing. If it isn't, bring in or refer a specialist. A legal requirement is a reason to be more careful, not less.

Be honest with yourself and the client, because accessibility compliance is genuinely a specialism and a half-done audit can do harm. There's a difference between building to a solid baseline — which any competent developer should — and conducting a formal conformance audit, which involves deep knowledge of the success criteria, real assistive-technology testing, the quirks of ARIA, and judgment calls about edge cases that aren't obvious. If you're not confident across that, taking it on risks delivering a report that claims a compliance the site doesn't actually meet, which is worse than no report at all, particularly when there's legal exposure. The professional move is to offer the baseline you can stand behind, and for formal compliance, either upskill genuinely or partner with an accessibility specialist and present that as a strength. Clients respect 'this needs a specialist and I'll bring in the right one' far more than a confident audit you can't actually back.

Because remediation means unwinding decisions instead of making good ones, and retrofitting always costs more than building right the first time. When accessibility is a goal from the start, it shapes the markup, the component structure, the color choices, and the interaction patterns as you go — it's woven in at low marginal cost. Bolting it on afterward means auditing a finished site, finding everywhere the existing structure fights the standard, and reworking components that were built without it in mind: refactoring markup, redoing focus management, sometimes changing a design that didn't account for contrast. You're paying to find the problems and then paying again to undo and rebuild. That's why a late 'make it WCAG compliant' is a remediation project, not a tweak, and why it deserves separate scoping. It's also the strongest argument for naming a conformance target at the start: the same compliance is dramatically cheaper as a design constraint than as a retrofit.

Pin down three things before you quote: the target level, the scope of pages, and whether you're auditing, remediating, or both. The target level matters enormously — WCAG A, AA, and AAA are escalating amounts of work, and AAA in particular is rarely fully achievable across a whole site, so agreeing the level prevents an open-ended chase. The page scope matters because 'make the site accessible' on a large site is a different job than on a handful of key templates; define which pages and patterns are in. And separate the audit from the remediation: an audit produces findings, remediation fixes them, and a client who only paid for one shouldn't assume the other. Add a conformance report as an explicit deliverable if they need documentation. With the level, the pages, and the audit-versus-fix boundary all named, the engagement has edges — without them, 'make it accessible' expands forever, which is exactly how unscoped compliance work consumes you.