Accessibility & VPAT-lite
DrawSplatTM Accessibility Statement
Current deployment scope
Use the wiki’s compliance and district review reference to match this document to your actual installation. Apps Script console controls apply to Drive/Sheets workflows; they do not automatically administer district MariaDB/MySQL private boards, rosters, assignments, submissions, or feedback. Templates and review packets do not establish a signed NDPA/DPA or certify legal compliance.
Plain-language summary of how DrawSplatTM approaches keyboard navigation, screen readers, contrast, motion, and reduced-bandwidth use, plus the known gaps. Written for district procurement reviewers who want a VPAT-style document but don’t need the full ITI VPAT 2.5 form filled out.
Commitment
DrawSplatTM aims to follow the WCAG 2.1 Level AA baseline. We treat accessibility as a constraint on every new feature rather than a separate workstream, and we welcome reports of gaps through Contact / Information Request.
Conformance summary
| Area | Status | Notes |
|---|---|---|
| Static marketing & legal pages | Supports | Semantic HTML, contrast ≥ 4.5:1 for body text, focus-visible outlines, no auto-playing media. |
| Whiteboard core tools | Partially supports | Keyboard shortcuts documented under Options → Keyboard Shortcuts. Tool buttons have aria-label, tooltips, and visible focus rings. Drawing on the canvas is mouse / touch / stylus driven; full keyboard-only board editing is a known gap. |
| Classroom widgets & games | Partially supports | Each standalone widget exposes labelled controls. Canvas-driven games (Tangram, Untangle, Flow Free, Castles) require pointer input today; pointer events route through pointerdown / pointermove / pointerup so touch and stylus work. |
| Compliance Console | Supports | Forms, dialogs, and tables use native semantics. Filter inputs accept keyboard. |
| Family Access Tools | Supports | Form fields have visible labels and aria-label. Required fields use both colour and a symbol. |
| Community Board | Supports | Posts and replies render plain prose with semantic headings; the Markdown renderer strips dangerous HTML and never auto-embeds external media. |
Specific features
Keyboard navigation
- Tab / Shift+Tab cycles every focusable control on every page; no positive
tabindexvalues are used. - Tool and action buttons activate with Enter / Space.
- Top-nav dropdowns use the native
<details name="landing-topnav">pattern so Enter / Space opens them and Escape closes them. - The Wheel Spinner canvas is a focusable
role="button"— Space / Enter starts the spin. - Known gap: drawing strokes, sticky-note repositioning, and shape resizing on the whiteboard canvas are not yet keyboard-driven.
Screen readers
- All interactive controls carry an
aria-labelmatching their visible text or icon meaning. - Icon-only buttons fall back to text via the
.icon-labelscreen-reader-only span and a visible tooltip on focus. - Live regions: status text in widgets and the Wheel Spinner result use
aria-live="polite". - Decorative images (illustrated heroes, brand logos in headers) use empty
alt=""; informational hero images describe their content inalt. - Known gap: the whiteboard canvas itself is not announced as a structured drawing surface; screen-reader users hear "DrawSplat whiteboard region" but not individual shapes.
Contrast & colour
- Body text against background tested at WCAG AA (4.5:1 or better) on every legal and marketing page.
- Status / result colours never rely on colour alone — e.g. the Untangle "intersection" indicator uses a count + a colour, and required form fields use a label + an asterisk.
- The Lights Out game offers three themes (Cyber Neon, Terminal Amber, Minimal Slate) so users can pick the contrast that works for them.
Motion & animation
- Wheel Spinner uses an ease-out spin animation. Decorative confetti respects screen size and decays in under three seconds.
- No game uses parallax or strobing effects.
- Planned: honor
prefers-reduced-motion: reduceon the Wheel Spinner and confetti.
Font scaling & zoom
- All pages set
<meta name="viewport" content="width=device-width, initial-scale=1">with nouser-scalable=no— pinch-zoom and browser zoom work everywhere. - Layouts use CSS Grid / Flexbox with
minmax(),clamp(), and percentage widths so zooming to 200% does not introduce horizontal scrollbars on the main content column.
Audio
- Every game with sound has a 🔊 / 🔇 mute toggle in the controls bar.
- Sounds are Web Audio synthesised — short blips and arpeggios — not narration. No essential information is conveyed only via audio.
Forms
- Every form field has a visible
<label>tied viafor. - Error messages render in a
role="status"live region close to the field. - The Contact form, Family Access Tools form, and post-composer all use semantic
<form>,<input>, and<textarea>— no custom widgets impersonating fields.
Assistive-tech tested with
Spot-tested with macOS VoiceOver in Safari and Chrome and with Windows NVDA in Firefox and Chrome. We have not yet completed a full structured audit. If your district’s VPAT process needs a specific assistive-tech matrix, send a request via Contact / Information Request.
Known gaps
- Canvas-driven keyboard drawing. Whiteboard shape creation, repositioning, and erasing require pointer input. Keyboard-only users can navigate the menubar and dialogs but cannot draw freehand strokes.
- Untangle / Flow Free / Tangram on keyboard only. These games require pointer drag. Mouse / touch / stylus input works; a keyboard-only fallback is on the roadmap.
- Reduced-motion preference. Some game spin / confetti animations don’t yet honour
prefers-reduced-motion; planned for the next minor release. - Localized screen-reader labels. Most UI strings are English;
data-i18nlabels in the Community Board are translated, but admin tooling is English-only. - Structured VPAT 2.5 document. The ITI VPAT form has not been completed in full. Available on request as a separately scoped service.
Report a barrier
If you hit an accessibility barrier, please file a report through Contact / Information Request. Include the page URL, the assistive tech (if any), and a short description of what didn’t work. We aim to acknowledge within five business days and to prioritise blockers that prevent a student from completing a classroom task.