Built so everyone can read along.

Our commitment

Lumora is built so that anyone — parent, grandparent, child, caregiver — can use it regardless of how they navigate the web. Our target is WCAG 2.1 AA conformance across every page in the product. We hold ourselves accountable to this target during design, implementation, and review.

Conformance status

Lumora is partially conformantwith WCAG 2.1 AA. "Partial" means we believe most of the product meets the standard, but some pages may have gaps we are actively working to close. If you find one, please report it — we treat accessibility issues as bugs.

What's implemented today

The following accessibility features ship in the product:

Keyboard navigation

• A "Skip to content" link is the first focusable element on every page, so keyboard and screen-reader users can bypass the header navigation in one Tab + Enter.
• Every interactive element (links, buttons, form controls) is reachable with the Tab key.
• Focus is visually indicated on every interactive element. The focus ring uses sufficient color contrast so it's visible on light and dark backgrounds.
• We do not trap focus inside modals without a way out (Escape closes; Tab cycles within the modal).

Screen reader support

• Each page has a unique <title> and a single <h1> for the main heading.
• Every page's primary content is wrapped in <main id="main"> so the Skip-to-content link lands in the right place and screen-reader landmark navigation works.
• Icon-only buttons (the "send", "close", etc.) have descriptive aria-label attributes.
• Error banners on forms use role="alert" so screen readers announce them immediately.
• The story-generation progress UI uses role="status" + aria-live="polite"so stage changes ("Brainstorming...", "Writing page 4...", "Painting the cover...") are announced as they advance, without interrupting the rest of the page.
• Photo upload status ("Uploading photo to slot 2...") also uses aria-live="polite".
• Form fields have visible labels and, where relevant, aria-describedby pointing at the help text or live region.

Touch targets

• Mobile tap targets meet the WCAG 2.5.5 (AAA) 44 × 44 px guideline on critical interactive elements: cookie banner controls, child-list rows, story-reader navigation, account-action buttons.
• We don't place tap targets adjacent without spacing — accidental taps are designed out.

Color and contrast

• Body text meets the 4.5:1 contrast minimum against its background. Large headings meet the 3:1 minimum.
• We don't use color as the sole means of conveying information. Errors carry both a red tone and an icon + label. Status indicators have text, not just color.
• Links are visually distinguishable from surrounding text (underline or weight, not just color).

Errors and feedback

• Form validation errors describe what's wrong and how to fix it, in plain language. We don't use raw error codes user-facing.
• When a server error happens during story generation, the fallback page describes what happened and offers a clear next action (retry, contact support, email a copy).
• Two error boundaries protect every page: a per-route boundary (app/error.tsx) for in-app crashes, and a layout-level boundary (app/global-error.tsx) for crashes inside the root layout itself.

Known limitations

These are areas where conformance is not yet complete. We consider them open bugs.

• Generated illustrations do not currently carry per-image alt text describing the scene. The surrounding story text serves the same content purpose, but a richer alt-text pipeline is on the roadmap.
• Audio narration (when enabled) does not yet have synchronized text highlighting. The story text is fully visible alongside the audio, but a karaoke-style read-along would be a stronger AAA-grade experience.
• Reduced-motion preferenceis honored on most animations but a few decorative transitions still respect the system setting only partially. We're auditing the remaining ones.

Assistive technology we test against

• Screen readers: VoiceOver (macOS, iOS), NVDA (Windows), TalkBack (Android).
• Keyboard-only navigation: Tab / Shift+Tab / Enter / Space / Escape patterns across every flow.
• Browser zoom: Layout holds at 200% browser zoom without horizontal scrolling on common breakpoints.

Reporting an issue

If something on Lumora isn't working for you, please tell us. Accessibility issues are bugs, and we fix them with the same urgency as functional ones.

• Email accessibility@lumora.kids or hello@lumora.kids with a description of the issue.
• Or use the contact form.
• If you can, include: the page URL, the device + browser + assistive technology you were using, and what you expected to happen.

We acknowledge accessibility reports within 1 business day, and aim to ship a fix or a workaround within 5 business days for blocking issues, longer for cosmetic ones.

Formal accessibility regimes

Lumora is operated from outside the EU but we serve EU users; we aim to meet the European Accessibility Act (EAA) expectations applicable to consumer digital services. We also aim to meet WCAG 2.1 AA as referenced by the US ADA, UK Equality Act, and Australian DDA accessibility guidance.

Questions

Write to accessibility@lumora.kids. A real human reads every email.