Standards
IS 17802 Accessibility Standard Explained
A practical guide to IS 17802, India's accessibility standard for ICT products and services, and how it affects audits, procurement, evidence, remediation, and retesting.
Quick answer: what is IS 17802?
IS 17802 is the Indian Standard for accessibility of ICT products and services. It was published by the Bureau of Indian Standards and is listed by the Department of Empowerment of Persons with Disabilities under standards and guidelines notified under the Rights of Persons with Disabilities Rules 2017.
For digital teams, IS 17802 matters because it goes beyond a simple website checklist. It can affect websites, apps, software, documents, hardware, support services, product documentation, procurement specifications, audit evidence, remediation, and retesting.
Why IS 17802 matters
Accessibility for ICT products and services is not limited to visual design. Users may interact with digital systems through keyboards, screen readers, captions, magnification, switch devices, voice input, accessible documents, platform accessibility settings, or support channels.
IS 17802 gives Indian organizations a standards-based reference for evaluating whether ICT products and services are accessible. It is especially relevant for public-sector work, procurement-sensitive projects, regulated digital services, education, BFSI, SaaS, and organizations that need evidence-led accessibility governance.
- It helps teams define accessibility requirements for ICT procurement.
- It supports audit scoping beyond only public webpages.
- It helps connect product, software, document, and support-service accessibility.
- It encourages evidence-based remediation instead of scan-only accessibility claims.
- It gives governance teams a standard to reference when reviewing ICT accessibility readiness.
How IS 17802 relates to EN 301 549 and WCAG
W3C's WCAG2ICT overview lists IS 17802 Part 1 and Part 2 as India standards based on EN 301 549. EN 301 549 is the European accessibility standard for ICT products and services.
This relationship matters because web content requirements inside ICT standards often connect back to WCAG. However, IS 17802 should not be reduced to WCAG alone. ICT accessibility may also involve documents, software behavior, hardware, support services, documentation, compatibility, and procurement requirements.
- WCAG is the core reference for web content accessibility.
- WCAG2ICT explains how WCAG 2 can be applied to non-web documents and software.
- EN 301 549 covers accessibility requirements for ICT products and services.
- IS 17802 is India's ICT accessibility standard based on EN 301 549.
- A serious audit should identify which standard, clauses, and content types are actually in scope.
What ICT products and services can include
ICT is broader than websites. In an audit or procurement review, the scope may include any digital product, service, interface, document, or support workflow that people need to use.
The exact scope should be agreed before testing begins because different ICT categories need different evidence and remediation owners.
- Websites, portals, web applications, and authenticated workflows.
- Mobile apps, software interfaces, kiosks, and digital platforms.
- PDFs, forms, statements, disclosures, learning material, and other digital documents.
- Hardware or closed ICT products where accessibility requirements are relevant.
- Product documentation, help systems, support services, training, and user assistance.
- Procurement specifications, vendor responses, and accessibility conformance evidence.
What an IS 17802 audit should clarify
An IS 17802 audit should not begin with a generic scan. It should begin with scope. The team should define which ICT products, services, documents, workflows, platforms, users, assistive technologies, and clauses are included.
This is important because a website-only review cannot support claims about mobile apps, PDFs, support services, hardware, or complete ICT procurement readiness unless those items are actually tested.
- Which ICT products and services are in scope?
- Which parts of IS 17802 are relevant to the engagement?
- Which WCAG version and level apply to web or document content in the audit scope?
- Which assistive technologies, browsers, devices, and operating systems will be used?
- Which exclusions, third-party dependencies, vendor systems, or technical limits should be documented?
- What evidence will be collected for findings and retesting?
Evidence expected in an IS 17802 audit report
A useful IS 17802 audit report should make findings understandable, reproducible, standards-mapped, remediation-ready, and retestable.
The evidence should match the type of ICT barrier. A web keyboard issue needs keyboard evidence. A document issue needs document structure evidence. A support-service issue may need process, documentation, or communication evidence.
- Scope, standard, clause mapping, methodology, and test environment.
- Finding ID, affected product, page, component, workflow, document, or service.
- User impact and affected user groups.
- Evidence such as screenshots, recordings, keyboard paths, screen reader notes, document checks, or support-service observations.
- Severity, remediation guidance, owner context, and retest requirement.
- Limitations, exclusions, third-party issues, and remaining risk.
Procurement and vendor readiness
IS 17802 is relevant to procurement because ICT accessibility should be considered before products and services are selected, not only after deployment. Procurement teams should ask vendors for evidence that maps to the relevant standard and product scope.
A vendor statement is useful only when it is specific. Broad accessibility claims should be supported by scope, testing method, standards mapping, exceptions, remediation plan, and retest evidence where available.
- Define accessibility requirements in the procurement scope.
- Ask vendors which ICT components, documents, and support services their evidence covers.
- Request standards-mapped accessibility documentation or audit reports.
- Identify exceptions, known gaps, third-party dependencies, and remediation commitments.
- Include retest or verification expectations for high-risk products and services.
Remediation planning under IS 17802
Remediation should be planned by product area and owner. Some findings may belong to engineering, while others belong to design, content, document remediation, procurement, support services, or vendor management.
A strong remediation plan should keep the original finding ID and clause mapping so closure can be traced from audit evidence to fix to retest result.
- Group issues by product, workflow, component, document type, or service channel.
- Prioritize critical and high findings that block essential tasks.
- Assign owners across design, engineering, QA, content, documents, support, procurement, and vendors.
- Define expected accessible behavior and acceptance criteria.
- Retest the original barrier after remediation instead of relying only on ticket closure.
How IS 17802 differs from a WCAG-only review
A WCAG-only review usually focuses on web content or content that can be evaluated using WCAG success criteria. IS 17802 can require a broader ICT view.
For many websites and web applications, WCAG mapping remains essential. But if the engagement includes software, documents, support services, hardware, procurement, or product documentation, teams may need IS 17802 clause mapping in addition to WCAG evidence.
- WCAG focuses on web content accessibility.
- WCAG2ICT helps explain WCAG application to non-web documents and software.
- IS 17802 addresses ICT products and services in the Indian standards context.
- An IS 17802 audit may need evidence beyond web page testing.
- The report should clearly separate WCAG mapping, IS 17802 mapping, and out-of-scope items.
Common mistakes to avoid
Weak IS 17802 readiness work often happens when teams treat the standard as a website scan or when procurement evidence is accepted without checking scope.
The safer approach is to define the ICT scope, map relevant requirements, collect evidence, remediate against owners, and retest closure.
- Reducing IS 17802 to only a homepage scan.
- Assuming WCAG AA alone covers every ICT accessibility requirement.
- Ignoring PDFs, documents, support services, product documentation, or vendor platforms.
- Accepting broad vendor claims without scope, evidence, or exceptions.
- Closing findings without retesting the original barrier.
- Using compliance language that the tested scope does not support.
Practical recommendation
Use IS 17802 as a structured accessibility reference for ICT products and services in India. Before the audit starts, define the ICT scope, relevant clauses, WCAG target where applicable, evidence expectations, remediation owners, and retest process.
For organizations managing websites, apps, documents, support channels, or vendor-provided ICT, an IS 17802-aligned audit can help create a stronger evidence trail than a scan-only accessibility review.
Official references used
DEPwD standards and guidelines notified under RPwD Rules 2017: https://depwd.gov.in/en/document-category/standards-guidelines-notified-under-the-rights-for-persons-with-disabilities-rules-2017/
PIB release on Indian ICT Accessibility Standards: https://www.pib.gov.in/PressReleaseIframePage.aspx?PRID=1826994&lang=2®=48
W3C WCAG2ICT Overview: https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/
BIS Know Your Standard: https://www.bis.gov.in/know-your-standard/?lang=en
W3C WCAG Overview: https://www.w3.org/WAI/standards-guidelines/wcag/