Accessibility

Effective from 7 August 2026. Version 1.0.

A product about developing capability cannot be one that some people are unable to operate. This statement covers the LifeCraft web application and the installable app built from it.

The standard we hold ourselves to

We target WCAG 2.2 Level AA across the whole product. In the child-facing mission views we go further and target Level AAA contrast for body text, because a child reading on a shared phone in poor light should not have to work for it.

What that means in practice

• Keyboard operable throughout. Every action, including the observation sliders, the mission flow and every dialog, can be completed with a keyboard alone. Focus is always visible, focus order follows the visual order, and nothing traps focus.
• Screen reader labels written at the reader’s level. In the child view the announced text is written in the language a child of that age band actually uses, not developer shorthand and not a repeat of the visual label. Every control says what it does and what state it is in.
• 200% zoom without loss. Zoom to twice the size, or set a larger text size in your browser, and no content, control or meaning disappears. Nothing requires horizontal scrolling to read.
• Never colour alone. Progress, pillar states, score changes and every success or warning carry a label, a shape or an icon as well as a colour. Charts present the same information as text you can read, so nothing depends on distinguishing two hues.
• Reduced motion respected. If your device asks for reduced motion, we honour it. Celebration animations become still, transitions are removed, and nothing moves, flashes or auto-plays.
• Touch targets sized for the age. In the views used by children under 10, interactive targets are at least 60 pixels, far above the minimum the standard asks for, because small fingers and imprecise aim are the normal case there.
• Forms that explain themselves. Real labels, not placeholder text. Errors say what is wrong and how to fix it, in words, next to the field concerned.
• No time pressure. Missions, reflections and observations have no countdowns and no sessions that expire while you are typing.
• Structure that makes sense unstyled. Correct headings, landmarks, lists and tables, a declared page language, and a meaningful page title on every screen.

How we check

Automated accessibility checks run in our build pipeline on every change, and a failure blocks the release rather than becoming a ticket. On top of that we test the main journeys with a keyboard only and with a screen reader, and we hold an audited target of at least 90 on Lighthouse in every category, with accessibility as close to 100 as we can get it. Automated tools catch perhaps half of what matters, so the manual pass is the one that counts.

Where we are not there yet

We would rather name these than let you discover them.

• Generated PDF reports and certificates are still being improved for reading order and tagging. If a PDF is hard to use, ask us and we will send you the same information in an accessible format.
• Payment pages belong to Razorpay and Stripe and are outside our control. We link to them, we do not build them, and their own accessibility statements apply there.
• Some data-dense views, such as institution cohort dashboards, are demanding on very small screens. The underlying information is always available as text.

Report a barrier

If anything in LifeCraft stopped you, tell us at accessibility@lifecraft.in. Include the page address, what you were trying to do, and what your browser and assistive technology are, if you know. Any level of detail is welcome; a single sentence is enough to start.

Our commitment when you do:

• We acknowledge within 5 working days.
• We tell you whether we can reproduce it and, if we can, when we expect to fix it.
• If the fix will take time, we give you another way to complete what you were trying to do in the meantime, including doing it for you.
• We treat a barrier as a defect, not a feature request. It goes into the same queue as anything else that is broken.

If you are not satisfied with how we respond, our grievance officer will take it up.

Changes

We review this statement whenever the product changes materially, and at least once a year. It reflects the state of the product on the date above, including the limitations listed, rather than the state we intend to reach.