Scormbusters accessibility status
What is implemented and tested, what was audited and fixed, and what we don't claim yet.
Last reviewed
This page covers two different things, because they are different things: the courses you publish(target: WCAG 2.1 AA, plus WCAG 2.2’s dragging criterion), and the authoring tool itself (target: ATAG 2.0), which an author using a keyboard or screen reader must be able to operate.
Every “supported” claim below is enforced by an automated test, and each is observable in an exported course. What is not yet done — a third-party audit, a full screen-reader pass — is stated here rather than omitted.
- Published courses target WCAG 2.1 AA plus WCAG 2.2's dragging-movements criterion (SC 2.5.7), which most authoring vendors formally concede ('Does Not Support') in their own reports.
- Every drag interaction in published courses has a single-pointer alternative (select, then place) and a keyboard path; SC 2.5.7 requires the single-pointer one, which a keyboard path alone does not satisfy.
- The authoring tool itself was audited against WCAG 2.2 AA and ATAG 2.0 Part A on 2026-09-17; the failures found (canvas not keyboard-operable, ~45 unnamed controls, systemic contrast, no announcements) are fixed and each fix is held by a test.
- No mainstream authoring vendor publishes an accessibility conformance report for its authoring application — only, sometimes, for published output.
- A third-party WCAG-EM audit has not yet been performed; that is stated on the page rather than papered over. No automated check proves WCAG conformance.
- Every published course embeds captions where stored, visible focus, non-color-only feedback, declared language and prefers-reduced-motion support; each is enforced by an automated test.
Published courses: what is implemented and enforced
| What is implemented | Criteria | Held by |
|---|---|---|
| Every drag interaction works without dragging — by single pointer (select, then place) and by keyboard. Matching, sortable, sequence and hotspot questions use native controls: dropdowns, move buttons, radio buttons per named area. | 2.5.7, 2.1.1 | A test fails if any block loses its single-pointer path |
| Hotspot questions are answerable without sight: areas are chosen by name from radio buttons, the picture outlined and numbered to match; the checker flags areas named only “Area 2”. | 1.1.1, 2.1.1, 2.5.7 | Import mapping + authoring checker |
| Captions are rendered wherever they are stored — in the player and in SCORM exports. | 1.2.2 | Player + export tests |
| Focus is visible in exported packages. | 2.4.7 | Export accessibility audit (axe, real Chromium) |
| Correctness is never conveyed by color alone; quiz feedback carries text and iconography. | 1.4.1, 1.3.3 | Block rendering tests |
| The page language is declared from the course locale, not hardcoded. | 3.1.1 | Export tests |
| prefers-reduced-motion is respected in the player and in exports. | 2.3.3 | Player + export implementation |
| Every published block type passes an axe-core audit of the real rendered output in a real browser. | multiple | npm run test:axe — runs in CI on every change |
A conformance claim on a specific course also depends on what its author wrote — alt text, color choices, heading structure. The built-in checker and the free scan find those problems; no automated tool can prove their absence.
The dragging criterion, and a correction worth recording
WCAG 2.2’s SC 2.5.7 asks for a single-pointeralternative to dragging — not a keyboard one. Someone on a head pointer or a switch-adapted mouse can press but cannot drag; a keyboard path does nothing for them. That distinction is the one most conformance reports get wrong, and the leading desktop authoring tools mark the criterion “Does Not Support” outright.
Until 17 September 2026 this project claimed 2.5.7 on the strength of its keyboard path alone. That was wrong, and it is recorded here rather than quietly edited. The single-pointer path now exists in every drag interaction, and the test suite fails if either block loses it.
The authoring tool itself (ATAG 2.0)
No mainstream authoring vendor publishes a conformance report for its authoring application — only, sometimes, for published output. Scormbusters’s authoring UI was audited against WCAG 2.2 AA and ATAG 2.0 Part A on 17 September 2026. It failed several Level A criteria. What the audit found, and what was done:
- The Scenes canvas was unusable without a mouse. Now: objects are tab stops announcing their type and selection state; Enter selects, F2 edits, arrows move, Alt+arrows resize; slide and layer panels are listboxes with roving tabindex. Held by a keyboard-operability test suite.
- About 45 properties-panel controls had no accessible name.The panel’s input primitives now require a name in their type signature — a control cannot ship without one.
- Text contrast failed systemically (the most-used text color sat at 2.5:1). Corrected across 68 files and held by a test that computes the ratios rather than trusting a convention.
- Nothing was announced. The app-wide toast had no live region and form errors were unassociated colored text. Both fixed — errors assertive, everything else polite.
ATAG Part B — the tool helping authors produce accessible content — is served by the built-in checker, first-class accessibility fields on every canvas object (alt text, tab order, ARIA), and import-time warnings for unnamed hotspot areas and undescribed images.
What is not claimed
- No third-party audit yet. The remediation above is recent and has not been assessed by anyone outside the project. The stated next step is a WCAG-EM-scoped third-party assessment, published on this site.
- No full screen-reader pass yet (NVDA, JAWS, VoiceOver). Keyboard operability is claimed; a good screen-reader experience on the freeform canvas is not — that remains an unsolved interaction problem across the industry, and pretending otherwise would be noticed.
- Scenes’ free-form drag objects are not graded. They can be operated without dragging in both players, but they are not scored or reported to the LMS; graded interactions use the matching and sequence questions, which the importers already emit.
Remaining gaps are tracked per-criterion in the project’s pre-deploy log, and accessibility defects are triaged as bugs. Every claim here can be checked against an exported course, which is what keeps this page honest.
Frequently asked questions
Do you have a VPAT or ACR?
Not a third-party one yet, and this page says so rather than papering over it. What exists today is stronger in one way and weaker in another than a typical vendor PDF: every supported claim is enforced by a named automated test, and anyone can check the behavior in an exported course — but no independent WCAG-EM assessment has been performed. The intent is a third-party audit published on this site with honest 'Partially Supports' rows, not a self-graded PDF on a file-sharing link.
Do courses published with Scormbusters meet WCAG 2.1 AA?
The player and exports implement the AA criteria that belong to the platform — captions rendering, visible focus, keyboard and single-pointer operation of every interaction, non-color-only feedback, declared language, reduced-motion support — and each is held by an automated test. Conformance of a finished course also depends on the content an author writes (alt text, contrast of chosen colors, heading structure), which the built-in checker flags but no tool can prove. No automated check proves WCAG conformance; a human review with assistive technology is still needed for a conformance claim on a specific course.
What is SC 2.5.7 and why does this page make so much of it?
WCAG 2.2's Dragging Movements criterion requires a single-pointer alternative to any drag — tap the item, then tap where it goes. A keyboard path does not satisfy it: someone using a head pointer or a switch-adapted mouse can press but cannot drag, and a keyboard alternative does nothing for them. The leading desktop authoring tools mark this criterion 'Does Not Support' in their own reports. Every drag interaction Scormbusters publishes has the single-pointer path, enforced by a test that fails if either block loses it.
Can the editor itself be used with a keyboard or a screen reader?
The authoring UI was audited against WCAG 2.2 AA and ATAG 2.0 Part A on 2026-09-17 and failed several Level A criteria; those failures are fixed and each fix is held by a test. The canvas is keyboard-operable: objects are tab stops that announce their type and selection state, arrows move, Alt+arrows resize, slide and layer panels are proper listboxes. Keyboard operability is not the same as a good screen-reader experience, and only the first is claimed; a full NVDA/JAWS/VoiceOver pass has not yet been run.
Why does this matter for ADA Title II or Section 504?
The ADA Title II web rule requires WCAG 2.1 AA for US state and local government web content — online courses included — by 2027-04-26 (entities serving 50,000+) or 2028-04-26 (smaller entities), and the HHS Section 504 rule by 2027-05-11 (recipients with 15 or more employees) or 2028-05-10 (smaller recipients). Procurement under those rules asks vendors for conformance documentation. This page is the living version of that documentation, with its evidence linked.
Who audits this?
Today: the project itself, with every claim tied to a test anyone can run, in a repository anyone can read. A third-party WCAG-EM assessment is the stated next step. Accessibility defects are triaged as bugs, not feature requests — an issue with a screen reader transcript is the fastest way to get something fixed.
See what your course looks like to a screen reader first
The free scan reads a published course zip or URL and reports accessibility problems, with a transcript of what a screen reader announces. No account; your course is uploaded for scanning only and deleted immediately, never kept.