Conformance target: WCAG 2.1 Level AA — Last updated: 2026-06-02
[DRAFT — Not yet legally reviewed] This document is the AA-280 Phase 2 drafter's working text. It has not been reviewed by counsel. Do not rely on this text. The draft: true flag and this banner are removed only when PUI-18 is closed by operator sign-off, per the AA-280 initiative's per-document review gate.
1. Statement of Commitment
Inspiration Dance LLC (the "Operator"), which operates the Avatar Animator service (the "Service" or "Platform") at codecandance.com, is committed to making the Service usable by the widest possible range of people, including students and educators with disabilities. Accessibility is a continuous engineering discipline for us, not a one-time audit: we build accessibility into our development process, we test on every release, and we publish our results.
This statement describes the standard we target, how we test against it, the gaps we know about today, and how to reach us if you encounter a barrier we have not yet fixed.
Effective date: 2026-06-02. Document version: 1.2.0.
2. Conformance Target — WCAG 2.1 Level AA
The Operator targets the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, published by the World Wide Web Consortium (W3C) as a W3C Recommendation.
Why WCAG 2.1 (and not WCAG 2.2 yet): WCAG 2.1 is the version referenced by the United States Section 508 Refresh and by the European EN 301 549 harmonized standard at the time of writing; it is the dominant procurement baseline for U.S. K–12 districts. WCAG 2.2 builds incrementally on 2.1 and we expect to migrate our target once the procurement landscape catches up; in the interim, we monitor 2.2 success criteria informally and implement them where the cost is low.
Why Level AA (and not Level AAA): Level AA is the consensus procurement floor for educational technology in the United States and the European Union. Level AAA includes criteria (e.g., 7:1 color contrast for all body text, sign-language interpretation for all video content) that are not commercially universal in ed-tech and would not, in our judgment, materially improve the experience of our actual user population. We do apply select Level AAA criteria where they serve our users (e.g., we expose user-controlled text resizing well beyond the AA 200% threshold).
3. Current State — Our Live Audit Report
We do not publish a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) attestation today. Authoring a formal VPAT 2.4 Rev (WCAG) requires a tested-coverage matrix produced against every Level A and Level AA success criterion, and we have not yet commissioned that work from an independent accessibility auditor. We believe filling in a VPAT without that underlying coverage matrix would constitute unsupported claims — worse, in our view, than publishing no VPAT at all.
What we publish instead is the candid current-state artifact: an automated axe-core scan of the Service's public-facing pages, regenerated on every release and served at a public URL.
- HTML view: /compliance/accessibility-report
- Raw JSON (for automated procurement workflows): /compliance/accessibility-report.json
The report covers pages reachable without authentication (home, login, signup, pricing, the four legal documents, sub-processors registry, and this Accessibility Statement). For each page, the report lists every detected violation by WCAG 2.1 success criterion and by severity (critical / serious / moderate / minor), with links into the Deque University remediation guidance. The report's frontmatter declares the axe-core version, the scan date, and the target base URL so that procurement reviewers can independently reproduce the scan.
This is the artifact we direct procurement reviewers to. If a reviewer requires a fuller conformance attestation, see Section 10.
4. Methodology — How We Test
We use a layered methodology combining automated checks, manual review, and user-facing feedback.
Automated axe-core in CI. The implementation lives at tests/accessibility/audit.ts and is invoked on every release via npm run accessibility:report. The scan iterates the public-page list above, runs axe-core 4.x against each page in a headless Chromium session via @axe-core/puppeteer, and writes the JSON report consumed by the public route. Pages with critical violations cause the audit script to exit non-zero; today no public page has a critical violation.
Manual keyboard navigation testing. We exercise the primary user flows (sign-up, login, project creation, Blockly workspace authoring, curriculum lesson navigation, district admin tabs) using keyboard input only, validating that focus order is logical, focus indicators are visible, and no surface is keyboard-trapped.
Screen-reader sampling. We sample primary flows on VoiceOver (macOS Safari) on every release cycle and on NVDA (Windows Firefox) on a quarterly cadence. We acknowledge that this is sampling, not exhaustive coverage of every screen-reader / browser combination.
Color-contrast review. axe-core flags AA contrast failures automatically; we additionally spot-check design-token changes against the WCAG 2.1 SC 1.4.3 contrast formula before committing.
Lighthouse accessibility audits. Lighthouse runs supplement axe-core for the page-load-time signals that overlap with accessibility (focus management on route transitions, ARIA attribute correctness).
Continuous user feedback. Accessibility issues reported via the contact path in Section 9 are triaged into the same backlog as any other defect.
5. Known Limitations and Roadmap
We are candid about the gaps that exist today. Detailed, per-page, per-criterion data lives in the live scan report; the items below summarize the categories that are material for procurement reviewers.
Moderate-severity issues on public marketing pages. As of the most recent scan, three public pages (/login, /signup, /pricing) carry a small number of moderate-severity axe-core findings — primarily missing-<main>-landmark, region-outside-landmark, and a meta-viewport user-scalable=no setting that disables pinch-zoom on mobile. The /pricing page additionally carries one serious-severity color-contrast finding and a heading-order discontinuity. None of these are critical-severity, but they are real and we are working through them.
3D viewer (WebGL). The Three.js / WebGL avatar viewer is, by the nature of the medium, not directly screen-reader-accessible. We provide keyboard-accessible alternatives for every animation and scene authoring operation through the Blockly block-based editor, and exported video artifacts can be reviewed without the live viewer. We document this limitation rather than overstate WebGL screen-reader support.
Blockly workspace. Avatar Animator's primary authoring surface is Google Blockly, which has its own accessibility model (keyboard navigation, screen-reader announcements) that we do not control and that has known limitations beyond ours. See Section 7 for the Operator's posture on third-party component accessibility.
Code editor panes. Where the Service exposes JavaScript / Python views of the underlying program (a paid-tier feature), it uses the Monaco / CodeMirror editors. Both have their own accessibility models inherited from their upstream projects. The editor panes are an acknowledged exception to our 16-point minimum-font-size policy (referenced in Section 7).
Authenticated surfaces not yet scanned. The current public scan covers unauthenticated pages only. Authenticated surfaces (the avatar editor, the curriculum lesson runner, the teacher and district admin dashboards, the chatbot Sam-tutor mode, and the Code Buddy lesson panel) are exercised through manual testing today; we plan to extend the automated scan to authenticated flows when our test harness supports authenticated headless sessions reliably.
Roadmap. Our prioritized accessibility roadmap is:
1. Close the public-page moderate findings (landmark-one-main, region, meta-viewport, /pricing color-contrast and heading-order). 2. Extend the automated scan to authenticated surfaces. 3. Commission an independent third-party accessibility audit once the automated coverage matrix justifies it; that audit, when complete, will support a formal VPAT 2.4 Rev (WCAG). 4. Track and migrate to WCAG 2.2 success criteria as the procurement baseline shifts.
6. Section 508 and EN 301 549
United States Section 508. The U.S. Federal Section 508 standard (refresh of 2017, codified at 36 CFR Part 1194) requires that information-and-communication technology used by federal agencies conform to WCAG 2.0 Level A and AA success criteria. Because our target of WCAG 2.1 Level AA fully encompasses WCAG 2.0 Level AA, our conformance posture is responsive to Section 508 to the same extent it is responsive to WCAG 2.1 AA. For more on the standard, see section508.gov.
European Union EN 301 549. The European harmonized standard EN 301 549 V3.2.1 (the basis for ICT-procurement requirements under the EU Web Accessibility Directive 2016/2102 and the European Accessibility Act 2025) likewise references WCAG 2.1 Level A and AA success criteria for web content. Our WCAG 2.1 AA target is responsive to the EN 301 549 web-content provisions to the same extent. EN 301 549 also contains non-web-content provisions (hardware, software, documentation) that do not apply to the Service's web application but may apply to the LED Cap / Vest hardware integration; we will address the hardware-side provisions as that part of the Service matures.
In both cases, a procurement reviewer who requires a standard-specific conformance statement (rather than the WCAG-2.1-AA statement here) may request one via the contact path in Section 9; we will produce a mapped statement against the relevant standard on request.
7. Third-Party Components and Acknowledged Exceptions
Parts of the Service are provided by third-party libraries whose accessibility characteristics we inherit and cannot directly remediate. We document them honestly rather than overstate our control.
Blockly (Google). The block-based authoring workspace is built on Google Blockly. Blockly maintains its own keyboard-navigation and screen-reader support; some complex drag-and-drop block interactions are mouse / touch-primary and have only partial keyboard equivalents. Blockly's authoring surface is governed by Blockly's own stylesheet, which is an acknowledged exception to the Operator's 16-point minimum-interface-font-size policy (the platform's chrome enforces a 16pt floor for interface text; the Blockly canvas operates under Blockly's own typography defaults to preserve compatibility with upstream block definitions).
Monaco and CodeMirror code editor panes. The paid-tier JavaScript / Python views use the Monaco and CodeMirror editor libraries. These editors render source code under their own typography defaults (typically smaller than 16pt to maintain conventional code-density expectations) and inherit their own accessibility models from upstream. The code-editor panes are an acknowledged exception to our 16-point minimum-font-size policy.
WebGL / Three.js 3D viewer. As described in Section 5, the WebGL viewer is not directly screen-reader-accessible; we provide keyboard-accessible alternatives through the Blockly authoring surface.
Embedded media. Where the Service embeds third-party media (stock-asset previews, AI-generated content thumbnails), the media inherits the captioning, alt-text, or transcript posture of its source; we do not represent equivalent accessibility for third-party media that the Operator did not generate.
8. Assistive-Technology Support
We test against the following combinations as our best-effort support matrix:
| Browser | Assistive technology | Test cadence | |---|---|---| | Safari (latest two versions) on macOS | VoiceOver | Every release | | Chrome (latest two versions) on macOS | VoiceOver | Every release | | Firefox (latest two versions) on Windows | NVDA | Quarterly | | Chrome (latest two versions) on Windows | NVDA | Quarterly | | Safari (latest two versions) on iOS | VoiceOver | Quarterly | | Chrome (latest two versions) on Android | TalkBack | Quarterly |
This is a best-effort, not guaranteed, support statement. We do not test every combination on every release; combinations not listed (e.g., JAWS on Windows, older browser versions, mobile Firefox) may work but are not part of our regular regression cycle. If you require support on a combination not listed, please contact us via Section 9 and we will prioritize accordingly.
9. Feedback and Accommodations
We welcome feedback on the accessibility of the Service. If you encounter an accessibility barrier, or if you need an accommodation that the current Service does not provide, please contact us:
- Email: darryl@inspirationdancecompany.ai
- Expected response window: Five (5) U.S. business days for initial
acknowledgment. Substantive resolution timelines depend on the nature of the issue; we will commit to a timeline in our initial response.
- Alternative-format provisions: If you require this Accessibility
Statement, the Privacy Policy, the Terms of Service, the DPA template, the Sub-Processors registry, or the Security page in an alternative format (large-print PDF, accessible HTML, plain-text, or a screen-reader-optimized version), please email the address above and we will provide one within ten (10) U.S. business days at no cost.
When reporting a barrier, please include (if you are able): the URL of the page where you encountered the issue, the assistive technology and browser you were using, and a description of what was not accessible. This helps us reproduce and fix the issue.
10. Procurement-Reviewer Notes
This Accessibility Statement, together with the live /compliance/accessibility-report, is the artifact the Operator publishes for procurement reviewers, including ed-tech SSO partners such as Clever and ClassLink (per our review of their public app-vetting documentation, both accept a WCAG-2.1-AA conformance statement supported by an automated-scan report; ClassLink acceptance is being confirmed in writing during partner onboarding).
If a school, district, state, or institutional procurement process requires a more formal document — a VPAT 2.4 Rev (WCAG), an Accessibility Conformance Report (ACR), a Section 508-specific attestation, an EN 301 549-mapped statement, a per-criterion supports / partially-supports / does-not-support matrix, or a written attestation of as-tested coverage — please contact us at the email address in Section 9. We will produce a tailored response, supported by our live scan and manual-test records, on the timeline negotiated with the reviewer. A formal third-party VPAT is on our roadmap (Section 5 item 3) and will be commissioned when the automated coverage matrix has been extended to authenticated surfaces and the known moderate-severity findings have been closed.
11. Contact and Version History
Operator entity: Inspiration Dance LLC Service domain: codecandance.com Compliance contact: darryl@inspirationdancecompany.ai Document last updated: 2026-06-02 Document version: 1.2.0
| Version | Date | Change | |---|---|---| | 1.0.0 | 2026-04 | Initial conformance statement. | | 1.1.0 | 2026-05-29 | Added live scan-report cross-reference and clarified VPAT posture. | | 1.2.0 | 2026-06-02 | AA-280 Phase 2 C refresh: expanded methodology, Section 508 / EN 301 549 mapping, third-party-component exceptions, procurement-reviewer notes, support matrix. Remains draft: true pending operator sign-off per PUI-18. |