TL;DR: A ₹50,000 WCAG audit is almost always an automated crawler, not a conformance audit. Crawlers structurally miss the WCAG issues that need human judgment. WCAG 2.2 added 9 new criteria in October 2023 that need manual screen reader testing, keyboard review, and code inspection. That work costs much more but produces a defensible VPAT. The gap between a cheap automated scan and a real audit is the gap between a PDF and a procurement gate you can pass.

Key Takeaways: - Automated tools have structural blind spots. They cannot judge any of the 9 new WCAG 2.2 criteria around focus visibility, target size, and accessible authentication. - A real audit has four phases: scope, manual assistive-tech testing, code review, and a remediation report with per-criterion evidence and screen reader recordings. - The price gap between an automated crawl and a manual audit reflects the difference between a crawler PDF and a conformance statement. A bank, insurer, or government buyer will accept the statement, not the PDF.

You paid ₹50,000. You got a PDF. The cover page had a logo.

The middle was a table of violations. The end was a checklist of "passes." You closed it, forwarded it to legal, and moved on.

That document was almost certainly generated by a crawler running axe, WAVE, or Lighthouse against a sample of URLs. A human added the executive summary on top.

The framing matters here. A crawl is not an audit. A crawl runs pattern matching against your rendered HTML.

It catches missing alt text, broken ARIA attributes, color contrast failures, and form labels without names. Those are the easy wins.

What a crawl cannot do is pick up a screen reader and listen to your checkout flow. It cannot tab through your site with a keyboard only. It cannot decide whether your focus indicator is hidden behind a sticky header on mobile.

For roughly ₹50,000, founders typically receive: - A small set of URLs scanned by an automated tool - A violation list with severity tags (critical, serious, moderate) - No screen reader testing - No keyboard-only navigation review - No VPAT or formal conformance statement - No code-level inspection of failure patterns like F70 or F34

This is the deliverable most entry-tier vendors offer. It is also the deliverable that will not survive procurement review at any bank, insurer, or government department.

Under the RPwD Act 2016, a non-conformant public-facing site is a litigation surface, not a checkbox. A crawler PDF does not inoculate you against that.

The problem is not that vendors are dishonest. It is that the tools they run cannot reach the floor WCAG 2.2 set in October 2023.

WCAG 2.2 became a W3C recommendation in October 2023. It added 9 new success criteria. Almost every one of them is a judgment call, not a regex match.

The criteria target users with cognitive disabilities, motor impairments, and low vision. They sit in the parts of the experience scanners cannot reach: focus visibility, touch target sizing, dragging, help, redundant entry, and authentication.

Take the F70 failure pattern. SC 4.1.1 demands correct start and end tags and attribute markup.

A scanner can check whether your tags balance. But balance is only the surface of F70. The real failures hide in attribute misuse, malformed components, and markup that a parser accepts but assistive technology cannot parse cleanly.

A human has to open NVDA or JAWS, navigate, and listen to detect the difference.

Then there is the F34 failure pattern. SC 1.3.1 and 1.3.2 require information and structure to be preserved.

F34 fires when authors lay out tables with white space characters instead of semantic markup. A scanner sees a block of text. A human sees a table that should have been a table.

The cost of that miss is real users getting lost in data they cannot parse.

The meta refresh failure is the clearest example of the scanner ceiling. When a `meta` tag has `http-equiv="refresh"` and a `content` attribute with a number but no `; url=`, the page auto-refreshes on a timer.

A scanner can flag the absence of `; url=`. It cannot tell you that a keyboard user is now trapped in a page that reloads before they can finish reading. That is a usability call.

Most of WCAG 2.2's new criteria need interpreting intent, not matching patterns. That is the structural limitation of every commercial scanner.

So what does WCAG 2.2 actually need that a ₹50K crawl never tests?

The 9 new success criteria break into four themes. Each one is something only a human with a screen reader, a keyboard, and time can judge. The automated tools that wrote your PDF saw none of them.

Focus visibility (3 criteria). 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), and 2.4.13 Focus Appearance. The standard requires that when you tab to a button, the focus ring is visible and contrasted. It must not hide behind a sticky header or cookie banner.

A scanner has no idea what is on top of your focus indicator on a real screen. A human tabs through your site and sees the gap. The pattern is so common it has its own failure mode worth tracking.

Pointer and touch (2 criteria). 2.5.7 Dragging Movements and 2.5.8 Target Size (Minimum). Dragging needs a non-drag alternative. Target size needs interactive elements to be at least 24 by 24 CSS pixels.

A scanner can measure static HTML. It cannot measure a real touch context or simulate thumb reach. It cannot judge whether drag-and-drop reorder is the only way to do something. A human tests with a finger, not a parser.

User help and data entry (2 criteria). 3.2.6 Consistent Help and 3.3.7 Redundant Entry. Help mechanisms must appear in the same relative order across pages. Users should not have to re-enter the same information across steps.

A scanner can check if a help link exists. It cannot walk a multi-step checkout and notice that the user typed their address three times. That is a flow review, not a page review.

Authentication (2 criteria). 3.3.8 Accessible Authentication (Minimum) and 3.3.9 (Enhanced). Cognitive function tests are out. Copy-paste must be supported for password managers.

A scanner reads the HTML. It cannot paste into a login form with a screen reader running. It cannot tell you whether the autocomplete attributes actually work for the user.

Each of those needs a human with a screen reader, a keyboard, and time. The protocol that catches them is a different category of work from a crawl.

A real audit is not a faster crawl. It is a different category of work. The protocol that catches WCAG 2.2 has four phases. Skipping any one is how cheap audits keep selling their PDFs.

Phase 1: Scope definition. Identify your primary page templates, critical user flows, and the conformance target.

Most teams pick WCAG 2.2 Level AA. Some enterprise deals ask for Level AAA on specific criteria.

A real audit names the templates, flows, and standards in writing up front. There is no ambiguity when the report lands.

Phase 2: Manual testing with assistive technologies. This is the part cheap audits skip. The minimum bar is NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android. Add a keyboard-only pass.

A tester walks each flow. They listen, tab, drag, and resize. They paste into login forms. They record what happens. This is the phase that finds F70, F34, and the meta refresh trap.

Phase 3: Code review. Inspect the semantic structure, ARIA usage, focus order, and the failure patterns crawlers flag inconsistently.

Look at the component library, not just the rendered page. A scanner sees what the browser renders. A human reads the source and asks whether the markup is correct in places the crawler never reached.

Phase 4: Remediation report. Per-criterion evidence. Screen reader recordings. Reproduction steps. Severity classification. A statement of conformance or non-conformance.

This is the document you hand to enterprise procurement, government buyers, and legal counsel. A crawler PDF is none of those things, and the absence of those artifacts is itself evidence of what was never tested.

The signal that a vendor has actually run this protocol at scale is hard to fake. Look for top accessibility audit companies in India with a deep track record across regulated industries. That volume only comes from teams that have done the manual work, not just the crawl.

That protocol has a real cost. The gap between ₹50K and a higher tier is not vendor markup. It is the difference between running a crawler and doing the work.

Put numbers on it. The math is the easiest way to see the gap.

₹50,000 buys: - A small set of URLs crawled by an automated tool - A violation list, often exported from axe or WAVE - A branded PDF with severity tags - Zero manual testing - Zero screen reader validation - Zero VPAT deliverable - Zero conformance statement

A real WCAG 2.2 AA audit for a mid-size SaaS product runs in the higher five-figure to low six-figure rupee range. The variables are template count, flow complexity, and the depth of the code review. Government and public sector RFPs under GIGW need a conformance report signed by a manual auditor. Crawler PDFs do not qualify. The procurement gate filters them out at the eligibility stage, before the technical evaluation even begins.

Catching issues in audit is far cheaper than catching them in a lawsuit response, a failed enterprise deal, or a government tender rejection. The remediation cost is the same either way. The downstream cost is not.

Vendors typically tier their offerings. The lower tier is the automated crawl. The higher tier is the manual audit. Vendors who refuse to describe the difference are the ones selling the PDF.

And the criteria your cheap audit passed? Some of them are probably wrong too. The crawler saw no violation and moved on.

A real audit changes what you can prove to a buyer. That is the whole point.

You get a defensible conformance statement. It is a document with a signature, a date, a scope, and a per-criterion verdict. You can hand it to enterprise procurement. You can hand it to government buyers. You can hand it to legal counsel when the question comes up. A crawler PDF cannot do any of those things.

You get a VPAT or ACR document. Voluntary Product Accessibility Template is the standardized format US federal agencies need under Section 508. A self-attested one will not survive a real procurement review. Indian BFSI and government buyers are increasingly mirroring that bar.

If you sell into regulated industries like banking, insurance, or healthcare, the VPAT is the gate. Without it, you do not get to the demo.

You reduce exposure under the RPwD Act 2016. You align with GIGW 2.0 for any government-facing portal. You get a remediation roadmap your engineering team can actually execute. Every finding has reproduction steps and a severity rating.

The gap between passing a crawl and surviving actual RPwD review is where most teams learn this lesson the hard way.

The same procurement bar that needs audited security now needs audited accessibility. Third-party verification by a human, not a tool, is the standard regulated buyers apply. Crawler PDFs fail the gate the same way self-attested SOC 2 reports fail it.

Work with a team that ships both the audit and the fixes, and the gate opens.

Q: How much does a WCAG 2.2 audit cost in India?

A: Automated-only crawls run in the low five-figure rupee range but miss most of WCAG 2.2. A manual WCAG 2.2 AA audit with screen reader testing, code review, and a VPAT deliverable typically runs in the higher five-figure to low six-figure range for a mid-size SaaS product. The cost scales with template count and user flow complexity.

Q: Are automated WCAG audit tools enough for compliance?

A: No. Automated tools have structural blind spots. They are weakest on the 9 new WCAG 2.2 criteria around focus visibility, target size, and accessible authentication. All of these need human judgment with assistive technology.

Q: What is a VPAT and when do Indian companies need one?

A: A VPAT (Voluntary Product Accessibility Template) is a standardized document showing how a product meets WCAG criteria. It is required for any sale to US federal agencies under Section 508. It is increasingly required by Indian BFSI and government buyers who mirror those procurement standards.

Q: Does the RPwD Act 2016 require websites to be WCAG compliant?

A: The RPwD Act 2016 mandates accessibility for persons with disabilities across digital services. GIGW 2.0 codifies WCAG 2.0 AA as the technical standard for government websites. Private sector enforcement is evolving through litigation. Enterprise and government contracts now routinely need WCAG 2.2 conformance evidence.

Q: How long does a proper WCAG 2.2 audit take?

A: A manual WCAG 2.2 AA audit typically takes weeks for a mid-size product with a meaningful template set. The bottleneck is manual testing with multiple screen readers and operating systems. It is not the crawl phase that cheap vendors compress into days.