Authoring captures intent
Alt text, captions, transcripts, glossary entries, and item-level accessibility metadata are first-class fields in the authoring workspace, not buried in a separate panel.
Accessibility
Accommodations are not a setting we sprinkled on top.
QTI 3 carries accessibility metadata and Personal Needs and Preferences as part of the standard. QFlowLearn carries those capabilities through authoring, into delivery, and out the other side as auditable evidence.
Pillars
Three places accessibility actually has to work.
PNP travels to delivery
Personal Needs and Preferences (PNP) profiles flow into the delivery runtime so accommodations like extra time, masking, color themes, and read-aloud are applied automatically per learner.
Evidence is exportable
Accommodation usage and access events are part of the attempt evidence ledger, giving teams defensible artifacts when an accommodation is contested or audited.
Accessibility support matrix
What is exportable now and what remains in the launch packet.
Accessibility evaluators see the same matrix as procurement. Status chips distinguish ready artifacts from launch-build artifacts. In build for launch means the capability is in scope for launch and the public RFP artifact is being assembled now.
| Capability | Notes | Status |
|---|---|---|
| Alt text & captions | Captured at the item level, surfaced in delivery, and validated on export. | Ready |
| Glossary / catalog support | Catalog support follows QTI 3 metadata so accommodations are portable, not vendor-locked. | Ready |
| Color themes & contrast | Color theme preferences are carried into the launch-time accommodation snapshot and exported with attempt evidence. | Ready |
| Extra time | Per-learner time extensions are captured at launch with both extra time and effective time limit evidence. | Ready |
| Answer masking | Masking state is captured in the launch snapshot, visible in instructor review, and exported in attempt CSV files. | Ready |
| Screen reader support | Keyboard-first navigation, semantic structure, ARIA on interactive widgets. Public test report is part of the launch packet. | In build for launch |
| Read-aloud / TTS | TTS and read-aloud state is flattened into attempt reports and exported as accommodation evidence. | Ready |
| Captions & transcripts | Caption and transcript availability is captured in the attempt accommodation summary. | Ready |
| Calculator & notes | Calculator and notes support are captured as shell-tool evidence when active for the learner. | Ready |
| Accommodation audit | Launch-time snapshot, source details, instructor timeline, learner reports, and CSV exports create defensible accommodation evidence. | Ready |
Procurement crosswalk
Map QTI 3 accessibility language to the RFP row.
Accessibility reviewers should not have to translate a standards page into a scoring sheet. The packet should crosswalk the RFP accommodation request, the QTI 3/PNP concept, the product behavior, and the evidence artifact.
| Procurement asks for | QTI 3 / PNP basis | QFlowLearn behavior | Status |
|---|---|---|---|
| Extra time and timing accommodations | PNP profile and delivery policy | Per-learner time extension resolved against attempt authority and receipt trail. | Ready |
| Answer masking or reduced answer set | Accessibility metadata and PNP-driven presentation | Masking behavior is captured in the launch-time accommodation snapshot and exported with attempt evidence. | Ready |
| Text appearance, contrast, and color-safe themes | Access for All and presentation preferences | Learner profile controls presentation without changing the underlying item content, and the active color theme is exported per attempt. | Ready |
| Read-aloud, captions, transcripts, glossary, and catalog resources | QTI accessibility metadata, glossary, catalog, and media alternatives | Authoring captures alternate resources, delivery exposes them, and active read-aloud, caption, and transcript support is recorded per attempt. | Ready |
| Screen reader and keyboard operation | Semantic interaction markup and accessible delivery rendering | Keyboard-first navigation, semantic structure, and AT rotation are part of the launch packet. | In build for launch |
| Accommodation usage reporting | Attempt evidence tied to learner presentation and delivery policy | Launch-time accommodation snapshots appear in instructor review, learner reports, and attempt CSV exports. | Ready |
| Calculator, notes, and learner support tools | PNP-driven support tools and delivery presentation state | Active shell tools are flattened into report summaries so reviewers can see which support tools were available. | Ready |
Our commitment
Accessibility is not a feature we'll get to. It's how the product is being built.
A VPAT is a snapshot. The work behind a credible VPAT is continuous: automated checks, manual rotation against assistive technologies, and structured sessions with disabled users. QFlowLearn is building the evidence program around all three.
Automated testing
The target testing program covers axe-core, Lighthouse accessibility audits, and Pa11y route sweeps in CI. The public reports are launch artifacts and will publish through the evidence library as they are finalized.
- axe-core component and route checks
- Lighthouse accessibility reports
- Pa11y route sweeps on staging
- WCAG 2.2 AA target across surfaces
Manual & assistive technology
Automated checks catch the obvious. The rest comes from humans driving the product with the same tools learners use: keyboard-only, screen readers, voice control, zoom, and high-contrast modes on a documented release cadence.
- NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari
- TalkBack on Android, VoiceOver on iOS
- Keyboard-only and switch-control passes
- 200%+ zoom and reflow regression
Testing with disabled users
Synthetic checks cannot tell us how a blind nursing student takes a high-stakes exam at 7:55am. We run moderated assessment sessions with real assistive-technology users and feed findings back into both authoring and delivery. Accessibility is a research practice, not a compliance line.
- Recruited assistive-tech users per release cycle
- Moderated high-stakes assessment scenarios
- Findings tracked publicly in the evidence library
- Disabled-led review of accommodations UX
VPAT / ACR: actively in production
We treat the VPAT as a living artifact, not a one-time deliverable.
Our Voluntary Product Accessibility Template / Accessibility Conformance Report is actively in production right now. We are running the WCAG 2.2 AA test plan against authoring and delivery, conducting assistive-technology rotations, and running user sessions with disabled learners. Each pass updates the VPAT, not just a spreadsheet.
Our public language stays honest until the VPAT is finalized: the support matrix is documented, the test plan is defined, the work is funded and underway. When the VPAT publishes, it links from this page and the evidence library. When it updates, the updated date is visible.
Procurement teams that need an accessibility statement before the public VPAT ships: ask. We will share the in-progress draft and current testing status under NDA so your accessibility reviewer can complete their evaluation without waiting on us.
Need an accessibility-specific evidence pack?
We will assemble the support matrix, accommodations coverage, and current testing status in a single packet for your accessibility reviewer.