Developers usually meet accessibility through WCAG findings: keyboard traps, missing labels, focus issues, contrast failures, invalid ARIA, or form errors.
IS 17802 expands the conversation because it deals with ICT products and services in the Indian standards context.
ICT is wider than web pages
Depending on scope, ICT accessibility can involve:
- Websites.
- Web applications.
- Mobile apps.
- Software interfaces.
- PDF and document outputs.
- Product documentation.
- Support services.
- Vendor platforms.
That is why scope is critical.
Where WCAG fits
WCAG remains the main reference for web content.
For developers, many IS 17802 audit findings may still look like WCAG work: semantic markup, keyboard support, focus management, accessible names, status messages, forms, media alternatives, and document accessibility.
But the audit may also ask for evidence beyond front-end code.
What a technical finding should include
A useful IS 17802-related finding should include:
- Affected product, screen, workflow, document, or service.
- Standard or clause mapping.
- WCAG criterion where applicable.
- Steps to reproduce.
- Expected behavior.
- Actual behavior.
- User impact.
- Evidence.
- Remediation guidance.
- Retest requirement.
That structure makes the finding actionable.
Retesting matters
After remediation, the original issue should be retested.
If the issue involved keyboard interaction, retest keyboard behavior. If it involved a screen reader, retest assistive technology output. If it involved a document, retest the document structure. If it involved support information, verify the updated support path.
Conclusion
IS 17802 is useful when teams treat it as an ICT accessibility framework, not only a website score.
Define the scope, map the requirement, collect evidence, fix the barrier, and retest closure.
Read the original guide on IAAP Audit: https://iaapaudit.com/blog/is-17802-accessibility-standard-explained
Top comments (0)