Accessibility Statement

Our commitment

ImpactMojo is a free platform for development education across South Asia. A platform that cannot be used by people with disabilities — by screen reader users, keyboard-only users, people with low vision, people with motor impairments, people with cognitive differences — is not actually free. It is free only to those whose bodies already match what the web assumed.

We treat accessibility as a baseline, not a feature. Every page we ship should be usable with a screen reader, navigable with a keyboard, readable at any zoom level up to 200%, and legible to someone with moderate colour-vision differences or low-contrast sensitivity.

Conformance status

Target: Web Content Accessibility Guidelines (WCAG) 2.1, Level AA.

Current status: Partially conformant. The core public pages of impactmojo.in meet WCAG 2.1 Level AA as measured by automated tooling (see below). Some third-party embedded content and legacy pages have known limitations that we are working through.

Scope: This statement covers everything under https://www.impactmojo.in/, including the homepage, course catalog, 11 flagship courses, 38 foundational 101 decks, 16 games, 11 labs, book summaries, blog, and policy pages. It does not cover external sites we link to.

Statement last updated: 8 April 2026.

How we test

Every pull request to main runs two independent accessibility audits before it can be merged. If either finds a serious or critical WCAG 2.1 AA violation, the build fails and the change does not ship.

axe-core WCAG 2.1 AA audit

We run axe-core against five high-traffic pages on every PR — the homepage, About, Catalog, BCT Repository, and a representative flagship course (courses/mel/index.html). The audit fails if it finds any serious or critical impact violation. Warnings at moderate or minor impact are reported but do not block merging.

pa11y-ci sitewide audit

We run pa11y-ci against thirteen pages that cover the breadth of the site: Home, Login, Signup, About, Catalog, BCT Repository, Premium, Account, Coaching, FAQ, Dojos, Dataverse, and Handouts. The standard is WCAG 2.1 AA. Four narrowly scoped rules are ignored — three are known HTML_CodeSniffer false positives on our input name attributes and one on a known-good contrast token — and these exceptions are documented in .pa11yci.

Manual review

Automated tools catch roughly 30–50% of real accessibility issues. For the rest, we do manual keyboard-only navigation testing, screen reader testing with VoiceOver and NVDA when we ship major new sections, and we read our own pages at 200% zoom to check that nothing reflows off the screen or becomes unreachable.

For the full story of how we got here — including the day we discovered our own site was lying about its accessibility state — read What It Actually Takes to Make an Accessible Website on our blog.

Accessibility features

• Semantic HTML5 throughout — proper landmarks (<nav>, <main>, <footer>), heading hierarchy, and form labels.
• Keyboard navigation on every interactive element, with visible :focus-visible outlines that survive colour-theme changes.
• Skip-to-content links on pages with long navigation headers.
• High-contrast colour tokens — body text meets at least 6.2:1 on light and 6.96:1 on dark, well above the WCAG AA requirement of 4.5:1.
• Dark mode + system-preference default — pages follow your OS setting on first paint, and an explicit System / Light / Dark toggle lets you override.
• 200% zoom without horizontal scrolling on any core page.
• Reduced-motion support — decorative animations disable automatically when prefers-reduced-motion: reduce is set.
• Inline link underlines in body text so links are distinguishable without relying on colour alone (WCAG 2.1 §1.4.1).
• UserWay accessibility widget available on every page for quick on-the-fly adjustments to text size, spacing, contrast, and readable fonts.
• Language translation via a built-in widget on key pages — Hindi, Tamil, Bengali, Marathi, and more are being rolled out.
• Captions and transcripts on video content where we produce it. Podcast episodes include show notes.

Known limitations

We are honest about what is not yet fully conformant:

• Gamma-hosted foundational courses. 34 of our 38 foundational 101 courses are currently embedded as Gamma.app iframes. These are third-party slide decks and we have partial control over their keyboard trap behaviour, colour contrast, and screen-reader labelling. We are progressively rewriting these as native HTML slide decks — 4 are already done (dev-economics, mel-basics, climate-essentials, inequality-basics).
• Course lexicons built with Parcel bundling. 17 book-companion pages were originally shipped without a full <head> tag because of the bundler. Meta tags have since been restored, but keyboard focus order on these pages may still feel inconsistent.
• Interactive games and labs. Some of our 16 games and 11 labs use custom canvas-based interactions (drag and drop, charts, timed simulations) that are challenging to make fully screen-reader accessible. We provide text alternatives and keyboard fallbacks where we can, but coverage is not yet complete.
• Embedded third-party widgets. The UserWay accessibility widget itself, the Intro.js tour system, and Google Translate are excluded from our automated audits because they are out of our source control. We audit manually where feasible.
• Automated tool coverage. Even a perfect axe-core + pa11y-ci pass only tests about a third to a half of the WCAG success criteria. Issues involving meaningful reading order, cognitive load, and genuinely equivalent alternatives for visual content can only be found by humans.

How to report an accessibility barrier

If you run into something that stops you from using ImpactMojo, please tell us. We treat accessibility reports as high-priority bugs, not feature requests.

• Email: hello@impactmojo.in with "Accessibility issue" in the subject line.
• GitHub: Open an issue in our public repository. Please add the accessibility label.
• In the message: tell us the page URL, what you were trying to do, what happened instead, and (if you can) what assistive technology and browser you were using. Screenshots or screen recordings are helpful but not required.

Our response commitment: we aim to acknowledge accessibility reports within two working days and to ship a fix or a clear plan within two weeks for serious or critical issues.

Standards and references

• Web Content Accessibility Guidelines (WCAG) 2.1 — the target we conform to.
• Authoring Tool Accessibility Guidelines (ATAG) 2.0 — relevant to the premium authoring tools we build.
• Deque University axe Rules Reference.
• Accessibility standards under Section 46 of the Rights of Persons with Disabilities Act, 2016 (India).

Changes to this statement

We update this statement whenever our testing infrastructure, known limitations, or scope of conformance changes materially. Historical edits are tracked in our public changelog.