Accessibility & VPAT-lite
SplatWorks Accessibility Statement
Security, privacy and terms covers the shared policy. This page provides the specialized reference or tool.
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
The implementation notes below concern the listed whiteboard, site, and classroom workflows. They are not a completed VPAT or a measured conformance claim for every SplatWorks app. Office editors and renamed standalone tools need their own keyboard, screen-reader, zoom, contrast, and media-accessibility review. Renaming does not establish accessibility parity.
| Area | Status | Notes |
|---|---|---|
| Static marketing & legal pages | Implementation notes; verify locally | 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 | Implementation notes; verify locally | Forms, dialogs, and tables use native semantics. Filter inputs accept keyboard. |
| Family Access Tools | Implementation notes; verify locally | Form fields have visible labels and aria-label. Required fields use both colour and a symbol. |
| Community Board | Implementation notes; verify locally | 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
- Labelled controls and visible focus are design goals. Validate accessible names and keyboard operation in the selected component; gaps should be reported.
- 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
- WCAG AA body-text contrast is the target. Verify the selected app, theme, screen state and user content; this page does not provide a measured all-pages contrast report.
- 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
Earlier documentation reported VoiceOver and NVDA spot checks; those are not a current test matrix for the whole ecosystem. No full structured accessibility audit or completed VPAT is supplied here. Review the selected component, version, assistive technology and browser, and report barriers through the contact page.
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.