Accessibility

India's Rights of Persons with Disabilities Act, 2016 establishes an accessibility framework, including provisions concerning standards and access to information and communication technology. Sector-specific standards may apply depending on the organisation and service involved.

For web design, we use the W3C Web Content Accessibility Guidelines (WCAG) 2.2 as the principal technical reference. We also review relevant practices in India's Guidelines for Indian Government Websites and Apps (GIGW 3.0), while recognising that GIGW is written for government websites and apps and is not presented here as a certification standard for this private Knowledge site.

Our design target is alignment with WCAG 2.2 Level AA where reasonably applicable to the current Knowledge experience. This is a development target, not a blanket conformance claim.

Formal conformance requires evaluating all relevant success criteria across complete processes and content. Automated tests can detect some failures, but they cannot establish full accessibility on their own.

Knowledge uses semantic HTML elements, heading hierarchy, native links, buttons and disclosure controls where practical so browsers and assistive technologies can understand page structure. Content should remain meaningful when visual styling is removed or when a user navigates by headings and landmarks.

Decorative elements are intended to be hidden from assistive technology where they do not convey information.

Core navigation, search, legal accordions, article controls and links are intended to be operable from a keyboard without requiring a mouse or touch gesture. Focus should remain visible and dialogs should support predictable keyboard movement and Escape-key dismissal where appropriate.

If a control traps focus, cannot be reached, changes context unexpectedly or lacks an accessible name, please report it as an accessibility defect.

Layouts are designed to reflow on small screens rather than depend on a fixed desktop canvas. Shared mobile QA checks representative pages at 320, 360, 390 and 430 pixel viewport widths for horizontal overflow and interaction problems.

Interactive controls are designed with touch-friendly sizing, and article reading size can be adjusted within the page. Browser zoom and operating-system text settings should remain usable without hiding essential information.

The Knowledge visual system uses restrained colour, text-first hierarchy and visible states rather than relying on colour alone to communicate meaning. We aim for readable contrast between text, controls and their backgrounds.

Where animation or smooth movement is used, the site respects the user's reduced-motion preference for supported interactions. Content should not require animation to be understood.

Published pages identify their document language in markup. Where an article is available in English and Hindi, Knowledge presents one language at a time with an explicit language switch so reading order is not duplicated or interleaved.

We aim to preserve meaning, headings, links and source references across language versions. Translation quality and accessibility should be reviewed together rather than treated as separate concerns.

Meaningful images should have text alternatives appropriate to their purpose. Data tables should preserve understandable headers and reading order, and wide tables may use horizontal scrolling on small screens rather than shrinking text beyond readability.

Linked PDFs, third-party documents and legacy resources can have accessibility characteristics outside the Knowledge template. If a document is difficult to use, contact us with the page or file name and the alternative format or information you need.

Knowledge changes are reviewed through version control and automated interaction checks, including mobile navigation, dialogs, article tools, language switching and overflow regression checks. We also use code review to catch structural issues.

These checks do not replace evaluation with screen readers, voice input, magnification, switch access or users with disabilities. Some external resources may remain less accessible than the Knowledge interface itself.

When reporting a barrier, include the page URL, the content or control affected, what you were trying to do, and—if you are comfortable sharing it—the browser, device or assistive technology involved. Do not include unnecessary personal or medical information.

If you need information in another accessible form, identify the specific document or content. We will review reasonable requests and the available source material.

Accessibility is reviewed when shared components, navigation, search, article templates, legal pages and downloadable resources change. We prioritise defects that block access to core content or tasks.

This statement will be updated when our accessibility target, testing process or material site architecture changes.