My recommendation, before the reasoning: build accessibility conformance you can evidence, not conformance you can assert. An automated scanner's pass is an assertion. A manual test plus a fix committed into the actual code is evidence. Both get written up in a report that looks the same length. They are not the same claim, and I've now lost two proposals over the difference between them — correctly, in both cases.
I run Samarthyam, a digital-accessibility practice, alongside two website engagements, a training program, and two document-remediation proposals that didn't convert. The pattern across all of it holds: the work that survives an audit is the work I can point to in the code, not the work a tool summarized for me.
What a scanner misses
Automated tools check what's mechanically checkable — a missing alt attribute, a contrast ratio below threshold, an unlabeled form field. That coverage is real and it's fast. It's also a small slice of what the standards actually ask. WCAG 2.2's Success Criterion 1.1.1, Non-text Content, requires that a text alternative serve an equivalent purpose — a scanner can confirm an alt attribute exists, it can't confirm the text inside it describes the image correctly, or that a purely decorative image was marked as such instead of read aloud as noise to someone using a screen reader. That judgment needs a person testing with a keyboard and assistive technology, not a crawler running a checklist.
The testing pass I run, under the Samarthyam brand, stacks three standards: WCAG 2.1/2.2, India's IS 17802 — the ICT accessibility standard that became mandatory under the RPWD (Amendment) Rules in 2023 — and GIGW 3.0, the Indian government's website-and-app guideline, itself harmonised to WCAG 2.1 at Level AA. One testing pass, three references: manual first, automated second to catch what scales, then remediation written straight into the code rather than handed back as a PDF someone else has to interpret and reprioritize weeks later.
An early engagement covering two related sites — Samarthyam's own site and a partner site for APNA — ran as one combined audit before I split it per site. Two activity logs, two scopes, two billing lines. It's a small operational choice, but it's the same discipline as the testing itself: don't let two different things get reported as one thing because tracking them together was more convenient on day one.
Where honesty cost the deal
The clearest lesson came from two document-accessibility proposals, both scoped honestly, neither converting into paid work — and I'd write the same recommendation again for either one.
The first was a prospective client's comic-format PDF, originally built in Canva. Independent testing put it at roughly 70% PDF/UA conformant — PDF/UA-1, formally ISO 14289-1, is the accessible-PDF standard, the rough equivalent of WCAG for the PDF format. The gap was specific and bounded: 82 of 114 figures were missing alt text, the cover title was split awkwardly across two elements, and reading order needed a manual verification pass. Every item on that list is an in-place fix — open the existing tagged structure, correct it, done. That's genuine remediation.
The second was another prospect's accessibility-toolkit PDF, and it looked, on the surface, like the same kind of job. It wasn't. Independent testing found it fully rasterized — 76 pages, every one an image, zero extractable text, no tags, no language attribute, no document title. The likely cause was a print-to-PDF export from whatever tool the toolkit was originally laid out in, a common production path that flattens a finished page into pixels and discards the text and structure a screen reader needs. There was no tag tree to repair, because none had ever been embedded in the file. The honest scope wasn't remediation. It was re-authoring from source.
I proposed the honest scope both times. The bounded remediation for the first didn't convert. The re-authoring engagement for the second didn't convert either — a harder sell than an in-place fix, and it should be, because it's asking for more, correctly. I could have scoped the rasterized file as if a lighter pass would get it most of the way there and let the real gap surface later on someone else's audit. That proposal probably wins more often. It also sells a result the work can't produce.
Code-level fixes, not a report
The distinction running under all of this: a findings report describes a gap. Remediation closes it. My website engagements for both APNA's site and Samarthyam's own are structured the same way — manual pass, automated pass, then the fix lands in the codebase itself, not in a slide the client's own engineers have to re-interpret and re-prioritize. A report is a claim about what should happen next. A commit is what happened.
The same instinct ran through a two-day WCAG training program I delivered for Bajaj Finserv's product and content teams — polished decks, a quiz and exam bank, and a live accessibility case study run against Bajaj Finserv's own website rather than a generic slide. A few planned extras — a second case study, a poll-quiz template, an MCQ bank — were dropped as not required once the core program was delivered and invoiced; shipping what's actually needed beats padding scope to look complete. Training against a real product is the same discipline as remediating in code over reporting on paper: the learner sees the actual gap in the actual interface, not a description of one.
What I'd tell someone starting a practice
- Run automated testing for what's mechanically checkable, fast. Run manual testing for everything a script can't judge — alt-text quality, reading order, keyboard traps, focus order.
- Split a combined engagement the moment it stops being one undifferentiated piece of work — per client, per site, whichever line the scope and the billing actually follow.
- Remediate in the code. A findings report is a claim; a shipped fix is the evidence.
- Before quoting a document job, check whether the file has an extractable text layer. If it's rasterized, the honest scope is re-authoring, not a discount version of repair — say so even when the smaller answer would close the deal faster.
- Where you can, train against the client's own product instead of a generic deck. A live case study is harder to build and lands harder once it's built.