If something here is not working for you, that is our bug — not yours.

The standard we target

WCAG 2.2 Level AA. The Web Content Accessibility Guidelines are the global reference for accessible web content. AA is the conformance level required by the European Accessibility Act (effective June 2025), most US state procurement rules, and most ADA-related court interpretations.

The site-wide statement at muntin.digital/accessibility.html covers the rest of the suite (tools, sheets, glossary, library). This page covers the bootcamp specifically — the 20 lesson pages, the 18 Workshop Kit widgets, the L14 generator, and the hub.

Where we are by WCAG principle

The four WCAG principles — Perceivable, Operable, Understandable, Robust — and how the bootcamp currently performs against each. Honest, not aspirational.

Accommodations we have shipped

• Screen-reader support. Every lesson is semantic HTML (<article>, <section>, proper heading order). Widgets announce state changes via polite live regions. Form inputs have real <label> elements with aria-describedby for help text.
• Keyboard navigation. Skip-link first in tab order on every page. All widgets reachable + operable via keyboard. Visible focus rings tuned for both light and dark mode.
• Reduced motion. The lesson-complete + module-complete celebration animations cancel under prefers-reduced-motion: reduce. The card itself still appears (information isn't motion-gated); only the reveal animation is suppressed.
• High-contrast mode. This page honors prefers-contrast: more; the lesson pages get the same treatment as the rollout reaches them.
• Bilingual. Every lesson, every widget, every sheet ships in English and Spanish. Hreflang stamped on every page so search engines + browsers route correctly.
• Color is never the only signal. Where status colors appear (audit ranking, generator readiness, deploy-stepper status), a textual label and/or position number carries the same meaning. Operators with color vision deficiency don't lose information.
• No autoplay. No audio plays without explicit operator action. No video. No animated decoration that runs continuously.
• Save-friendly. Progress lives in the operator's browser (or in their Muntin account if signed in). Closing the tab is safe; coming back resumes at the same lesson with the same state.

Keyboard navigation reference

Every bootcamp interaction is keyboard-reachable. Here's what to expect from each widget. If a widget you encounter doesn't match this list, report it — that's a bug.

No bootcamp-specific keyboard shortcuts (no Cmd+S or similar). The reasoning: shortcuts that override browser defaults (autosave, save-as) confuse screen readers and conflict with assistive technology. The standard Tab + Enter + arrow keys cover every interaction in the bootcamp.

What we are still working on

These are the accommodations the bootcamp's instructional-design audit identified as not-yet-shipped. They are tracked in docs/course-instructional-audit.md.

Audio narration (in flight)

Every lesson can ship a 5-8 minute audio narration. The pipeline + manifest are ready (40 lessons × 2 locales = 40 MP3 files declared as pending). Recording is happening operator-side; you will see a "Listen to this lesson" button appear next to the lesson title once a track is rendered. Particularly valuable for blind operators, dyslexic readers, and anyone doing the bootcamp while cooking or driving.

Plain-language alternative per lesson

The lessons today are written at a college reading level. Plain-language versions (target: 7th-8th grade reading, shorter sentences, no metaphors) will land as a <details> block at the top of each lesson, opt-in. Useful for ESL operators, operators with reading-comprehension disorders, and operators who simply want the fast version.

Glossary term-link density

Domain terms like "GBP", "schema markup", "NAP consistency", "CNAME" appear in the lessons; not all of them link to the glossary yet. The Method tenet "One vocabulary, owned" expects every term that matters to be inline-linkable. Rolling out per-lesson.

Touch-device testing pass

The bootcamp works on phones (we test in Chromium devtools), but a real-operator touch-device test with 3-5 operators in their actual kitchens is on the schedule. Findings will land as a punch list on this page.

What we are NOT doing (and why)

Honesty about scope. These are accommodations the bootcamp deliberately does not include — either because they are not in the standard or because they conflict with another constraint we hold higher.

• No audio captions on the future audio narration. The narration will be a literal reading of the lesson text — which is on the same page. Captioning the audio would duplicate the text. If you want to read, read; if you want to listen, listen. Deaf operators get the canonical experience (the written lesson); blind operators get the narration. Neither needs the other's accommodation duplicated.
• No third-party accessibility-overlay widgets. Overlay tools (UserWay, accessiBe, etc.) introduce JavaScript that fights with screen readers and can actively make accessibility worse. They also fetch third-party scripts, which violates our no-fetch posture. We do real accessibility work instead.
• No simplified "easy English" version. The plain-language alternative is the right granularity. A separate easy-English version would fragment maintenance without serving an audience the plain-language version doesn't already serve.
• No automated translation beyond EN + ES. The Spanish version is hand-edited for voice. Machine-translated French / Italian / Portuguese / Chinese versions would be technically possible but the voice register would degrade. Audio narration in those languages is already pipelined; written lessons will follow if there's audience signal.

Report something that's not working

Last reviewed

This page: 2026-05-25. Re-audit cadence: every 90 days, or sooner if the bootcamp adds new widgets, new lessons, or new third-party dependencies.

Suite-wide statement: /accessibility.html · Audit doc: docs/course-instructional-audit.md