DEV Community

IAAP Audit
IAAP Audit

Posted on • Originally published at iaapaudit.com

IS 17802 vs WCAG: Audit Scope Guide

A developer-focused guide to IS 17802 and WCAG mapping for Indian accessibility audits, remediation, evidence, and retesting.

If you are a developer or QA engineer working on an accessibility audit in India, the standard named in the audit scope changes the work you will receive.

A vague issue like accessibility problem is hard to fix. A standards-mapped issue with steps, expected behavior, user impact, and retest criteria is useful.

That is where WCAG and IS 17802 need to be understood correctly.

WCAG is the implementation-friendly baseline

WCAG is usually where web defects become actionable. It gives a way to map a problem to a specific success criterion.

Examples:

  • A button has no accessible name.
  • Focus disappears behind a sticky header.
  • A modal traps keyboard users.
  • A form error is visual only.
  • A PDF link has no meaningful text.
  • A touch target is too small.

These are not abstract compliance notes. They are implementation defects that affect real users.

IS 17802 is not just another label for WCAG

IS 17802 is the Indian ICT accessibility standard. If the buyer asks for it, the report may need to do more than map common web defects to WCAG.

Depending on scope, it may involve broader ICT products and services, documentation, documents, support content, apps, procurement evidence, and conformance reporting expectations.

For engineering teams, the lesson is simple: ask what the report must map to before remediation starts.

What useful audit tickets look like

A strong accessibility issue should include:

  • What failed.
  • Where it failed.
  • How to reproduce it.
  • Who is affected.
  • Which standard is mapped.
  • What the expected behavior is.
  • What remediation approach is recommended.
  • How the fix will be retested.

Without those details, teams waste time debating the issue instead of fixing it.

Why manual testing still matters

Automated tools can flag markup and some programmatic failures. They cannot reliably validate the full user journey.

Manual review is needed for:

  • Keyboard-only completion.
  • Logical focus order.
  • Screen reader context.
  • Form recovery.
  • Modal behavior.
  • Meaningful alt text.
  • Document structure and reading order.
  • Real task completion.

That is why an accessibility audit should combine scanning, expert review, assistive technology checks, and retesting.

How to prepare the codebase

Before audit handoff, teams can reduce noise by checking basics:

  • Use semantic HTML before custom ARIA.
  • Make every interactive control keyboard accessible.
  • Ensure visible focus is not hidden.
  • Connect labels, descriptions, and errors to form fields.
  • Test key journeys without a mouse.
  • Check PDFs and downloadable documents separately.
  • Keep component behavior consistent across pages.

Conclusion

For developers, WCAG usually explains the web defect. IS 17802 may explain why the buyer needs India-specific ICT accessibility evidence.

Treat both as scope inputs. The better the audit mapping, the faster the remediation cycle becomes.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/is-17802-vs-wcag-indian-organizations-guide

Top comments (0)