Accessibility in Knowledge Quest Studio
Every feature in Knowledge Quest Studio is designed so that students with disabilities can participate fully - not as an afterthought, but as a core requirement. This page documents exactly what we do, how we do it, and which WCAG 2.1 success criteria each implementation satisfies.
Our Commitment
Knowledge Quest Studio is built for educators who serve diverse student populations - including students who are blind or have low vision, students who are deaf or hard of hearing, students with motor disabilities who rely on keyboards or switch access, and students with cognitive or vestibular disorders. Accessibility is not a compliance checkbox here; it is a design constraint applied to every feature from the start.
We believe that a lesson tool that excludes any student is not a good lesson tool. If you find a barrier that prevents a student from using a published lesson, please contact us - we treat accessibility bug reports as high-priority issues.
Scope & Conformance Target
Published lessons (the SCORM packages students open in an LMS, and lessons opened via the browser preview) target WCAG 2.1 Level AA conformance. This is the level required by most institutional accessibility policies, the Americans with Disabilities Act (ADA) technical guidance, and Section 508.
The authoring editor (the tool teachers use) targets WCAG 2.1 Level AA for all core workflows: creating slides, writing questions, and running the Accessibility Checker. Some advanced panels (the AI tools) are Level A.
Several features exceed Level AA and implement WCAG 2.1 Level AAA requirements - notably the motion reduction support for block animations (Success Criterion 2.3.3).
Keyboard Navigation
Every interactive element in a published lesson is reachable and operable using a keyboard alone - no mouse required. This supports students who have motor disabilities, use switch access devices, or prefer keyboard navigation.
Slide navigation
Previous and Next buttons are standard <button> elements reachable
with Tab and activated with Enter or Space. Focus order
follows the visual reading order of the page.
Quiz questions
Multiple Choice and True/False questions use native radio button groups wrapped in
<fieldset> and <legend> elements. Students navigate
with arrow keys within the group and Tab between groups. The Submit button is a
standard <button>.
Branching scenario choices
Each scenario choice is a <button> with a descriptive label taken
directly from the teacher-authored choice text. All choices are reachable by Tab and
activated by Enter or Space.
Reveal / hidden sections
Reveal buttons use aria-expanded to communicate the open/closed state
to assistive technologies. When a section opens, focus is not moved - content flows
naturally in the reading order below the button.
Scrolling panels
Scrollable content panels are focusable with Tab and scrolled with arrow keys once focused, following the standard scrollable region pattern.
Screen Reader Support
Published lessons are structured so that screen reader users (students who are blind or have low vision) receive the same information as sighted students, in a logical order.
Semantic HTML structure
Each slide is a <section> element with a heading hierarchy
(<h1> for the slide title, <h2> for sub-sections).
Slide content follows a single-column reading order that matches the visual layout.
Decorative icons are marked aria-hidden="true" so screen readers skip them.
Page and slide titles
The browser <title> element includes the lesson name. Each slide's
heading is announced when the slide loads, orienting screen reader users immediately.
The Accessibility Checker flags any slide with a missing title before the teacher exports.
Status messages and live regions
Quiz feedback (correct/incorrect), score totals on the Results slide, and position
announcements in the Sequence quiz are delivered via aria-live="polite"
regions. Screen readers announce these updates without moving focus away from the
student's current position.
Image alt text
Every image block in the authoring editor has an Alt Text field. The editor displays a contextual example placeholder, an amber warning border and "Missing" indicator when an image is present without alt text, and the Accessibility Checker flags missing alt text as an error before export.
- Informative images: alt text describes what the image shows.
- Decorative images (when teacher marks as decorative): rendered with
alt=""so screen readers skip them. - Alt text longer than 125 characters triggers a Checker warning recommending a caption instead.
- Alt text that looks like a filename triggers a Checker warning.
Language declaration
All published lessons include lang="en" on the root <html>
element, allowing screen readers to select the correct speech synthesizer voice and
pronunciation rules.
Skip navigation
A "Skip to main content" link is the first focusable element on the lesson page. Keyboard and screen reader users can activate it to jump past the lesson header and navigation controls directly to the slide content.
Quiz Interactions
Knowledge Quest Studio supports five quiz types. Each one is designed so that students with motor disabilities, screen reader users, and keyboard-only users can complete it without assistance.
Multiple Choice
- Questions use
<fieldset>+<legend>so screen readers announce the question stem before each answer option. - Answer options are
<input type="radio">elements with visible<label>elements - no custom styling that removes native semantics. - After submission, correct/incorrect feedback is injected into an
aria-live="polite"region so screen readers announce it without focus moving. - Correct answers are indicated by both color and an icon (✓ / ✗) - never by color alone.
True / False
- Each statement is grouped with its True/False buttons in a
<fieldset>/<legend>. - True and False are radio buttons - navigable with arrow keys, no mouse required.
- Optional teacher-authored feedback text is announced via
aria-liveafter submission.
Matching
- Click-to-select interface: students click a term, then click a definition. Both are standard buttons with descriptive labels.
- Selected state communicated via
aria-pressedon term buttons and visual highlighting that is not color-only. - All interactions operable by keyboard Tab + Enter.
Fill in the Blank
- Each input has a visually hidden
<label>and anaria-describedbyattribute pointing to the feedback element, so screen readers can announce the feedback without the student having to navigate to it. - When an answer is marked incorrect,
aria-invalid="true"is set on the input - screen readers announce this state and the error description. - Feedback is delivered via
role="status" aria-live="polite"so it is announced without moving focus. - Matching is case-insensitive by default. This prevents students from being marked wrong for minor capitalization differences that do not affect the meaning of the answer (e.g., "atp" accepted when the answer is "ATP"). Teachers enable case-sensitive matching only when capitalization is semantically meaningful.
- Multiple accepted answers per question allow teachers to accept common spelling variations, so students are not penalized for legitimate alternative spellings.
Sequence / Order
This is the most accessibility-intensive quiz type, because drag-and-drop is the primary interaction and drag-and-drop is inherently inaccessible without alternatives.
- Keyboard alternative - required by WCAG 2.5.1: Every item has a visible ↑ Up and ↓ Down button. Students can reorder the entire list using only these buttons and a keyboard, with no drag-and-drop required. This satisfies the Pointer Gestures criterion (SC 2.5.1), which requires that all functionality operable by drag can also be operated by a single pointer action.
- Live position announcements: When a student moves an item with
the Up/Down buttons, an
aria-live="assertive"region announces the new position (e.g., "Step 3 moved to position 1 of 5"). Screen reader users always know where each item is in the list. - Each list item and its buttons have
aria-labelattributes that include the item text and current position, so screen readers can read the full state of the list at any time. - Correct/incorrect result is announced via
aria-liveafter Submit.
Motion & Entrance Animations
Content blocks (paragraphs, callouts, card grids, flip cards, timelines) can be given optional entrance animations - fade-in, slide-up, or pop-in - that play when a slide first appears. Vestibular disorders (such as labyrinthitis or BPPV) can cause nausea, dizziness, and disorientation in response to on-screen motion. WCAG 2.1 addresses this at Level AAA (SC 2.3.3 Animation from Interactions).
prefers-reduced-motion
All entrance animations are implemented exclusively inside a
@media (prefers-reduced-motion: no-preference) block. When a student has
enabled the Reduce Motion accessibility setting in their operating
system (macOS, Windows, iOS, Android all support this), the CSS block does not apply:
- Blocks are rendered at full opacity and their final position from the start - no animation occurs at all.
- Content is never hidden or delayed, regardless of the user's motion preference. Animations are purely cosmetic; they do not gate access to content.
- There is no JavaScript detection required - the browser enforces the media query natively, so it works even in restricted or high-contrast browser modes.
Teacher guidance at point of authoring
Whenever a teacher selects an animation in the editor, an inline note appears immediately below the animation picker: "Animation is automatically hidden for students who use Reduce Motion settings - content is always fully visible." This appears and disappears in real time as the teacher changes the setting, so they don't need to search the documentation to understand the accessibility behavior.
Completion Certificates
When a student passes a lesson, a Get Certificate button appears on the Results slide. Clicking it opens a print-ready certificate overlay. The overlay is implemented as an accessible modal dialog.
Modal dialog implementation
- The overlay element has
role="dialog",aria-modal="true", andaria-labelledbypointing to the certificate heading - screen readers announce "dialog, Certificate of Completion" when it opens. - Focus is moved into the dialog when it opens (to the student name field), so keyboard users immediately land inside the correct context.
- Focus is trapped inside the dialog while it is open. Tab cycles through the dialog's focusable elements (name field, Print button, Close button) and does not escape to the page behind. This prevents the disorienting experience of activating controls outside an open dialog.
- The dialog is closed by clicking the × button, clicking the backdrop, or pressing Escape. All three methods work by keyboard.
- Focus returns to the "Get Certificate" trigger button when the dialog closes, so keyboard users are not lost on the page.
Color & Contrast
Minimum contrast ratios
All lesson color palettes are designed with a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt+ bold) against their backgrounds, meeting WCAG Level AA requirements. The palette editor in Lesson Settings only offers compliant color combinations.
Color is not the only signal
Quiz results (correct/incorrect) use both color and a text icon (✓ for correct, ✗ for incorrect). Pass/fail status on the Results slide uses both color and explicit "Pass" or "Needs Review" text. Students who are colorblind or who use high-contrast mode receive the same information as students who see color normally.
Text resize
Published lesson text is set using relative units (rem, em,
%) so that browser-level text zoom (up to 200%) does not cause horizontal
scrolling or loss of content.
Audio & Dialog Simulation
Slide audio - narration and background music
Instructors commonly record themselves narrating the slide text to create instructor presence. This is fully accessible: when the audio narrates content that is already written on the slide, the visible text serves as the transcript under WCAG 1.2.1 (the "media alternative for text" provision). Students who are deaf or hard of hearing receive the complete lesson content through the visible text; the audio is supplementary.
The editor reminds instructors of one key rule: audio must not add information that is not also present in the slide text. Any content spoken but not written would be inaccessible to students who cannot hear it. The in-editor narration tip communicates this guideline at the point of authoring.
Background music and ambient audio are decorative and non-informational by nature. All audio - whether narration or music - can be paused or stopped by the student at any time via the play/pause control on every slide (WCAG 1.4.2 Audio Control).
Dialog simulation slides
Dialog simulation slides display a conversation between named characters. The full text of every dialog line is displayed on screen as the conversation advances - it is never audio-only. Students who are deaf or hard of hearing read the conversation text. Screen readers announce the character name followed by the dialog line for each step.
- Character names are required - the Accessibility Checker flags unnamed characters as errors, because screen readers cannot identify who is speaking without a name.
- Optional per-line audio (voice acting) is supplementary; the text is always present and the lesson is fully usable without audio.
Accessible Authoring Tool
Accessibility is most effective when teachers are supported in making accessible content decisions at the moment they are authoring - not after the fact. Knowledge Quest Studio builds accessibility guidance into the editor at every relevant point.
Alt Text Guidance at Point of Authoring
Contextual example placeholder
The alt text field on every image block shows a concrete example in the placeholder text - "e.g. Nurse checking a patient's blood pressure" - rather than the generic "Enter alt text." This models good alt text writing rather than just labeling the field.
Live missing-alt warning
When an image is present in an image block but the alt text field is empty, the field border turns amber and a "Missing - please add alt text" message appears immediately below the field. The warning clears as soon as text is entered. This gives teachers real-time feedback without requiring them to run a separate check.
HelpTip tooltip on the label
A question-mark icon next to the Alt Text label opens a tooltip explaining why alt text matters and what "describe what the image shows" means in practice - linking the requirement directly to the student experience.
Built-in Accessibility Checker
The Accessibility Checker is a live panel in the editor sidebar that runs automatically as teachers build their lesson. It categorizes issues by severity and explains how to fix each one in plain language - no accessibility expertise required.
Live badge in the sidebar
The Accessibility Checker navigation button displays a live count badge: red for errors, amber for warnings. The count updates in real time as the teacher edits the lesson - teachers can see at a glance whether their lesson has unresolved issues without opening the panel.
What the Checker catches
- Images: Missing alt text (error), alt text over 125 characters (warning), alt text that looks like a filename (warning).
- Links: Non-descriptive link text such as "click here" or "read more" (warning) - WCAG 2.4.4 Link Purpose.
- Slide titles: Any slide without a title (error).
- Videos: Embedded video without a title attribute (warning).
- Branch slides: Choices with no destination (error), choices with no button label (error).
- Dialog slides: Characters without names (error), dialog with no lines (warning).
- Fill-in-the-Blank: Questions with no prompt (error), questions with no accepted answers (error).
- Sequence/Order: Fewer than 2 items (error), blank item text (error), missing instruction prompt (warning).
- Course structure: Results slide without any quiz slides (warning), lesson with no slides (info).
Plain-language fix instructions
Every issue includes a Fix: explanation written for teachers without accessibility expertise - for example: "Add a brief description of the image in the 'Alt text' field. This is what screen readers say aloud when a student reaches the image." The explanation connects the technical requirement to the student's actual experience.
Full WCAG 2.1 Criterion Mapping
The table below lists every WCAG 2.1 success criterion that applies to Knowledge Quest Studio published lessons, the conformance level, implementation status, and a brief implementation note.
| Criterion | Level | Status | How it is met |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Supported | Alt text fields on all image blocks; Checker flags missing alt text as error; decorative images use alt="" |
| 1.2.1 Audio-only (Prerecorded) | A | Supported | Narration audio reads slide text that is already visible on screen - the visible text serves as the transcript (media alternative for text provision). Instructors are guided not to add audio-only information. Dialog simulation text is always visible on screen. |
| 1.2.2 Captions (Prerecorded) | A | Partial | Self-hosted video: captions authored by teacher displayed via <track>. YouTube/Vimeo: relies on platform captions - teacher must verify |
| 1.3.1 Info and Relationships | A | Supported | Semantic HTML throughout: headings, lists, fieldset/legend for quiz groups, ARIA roles where HTML semantics are insufficient |
| 1.3.3 Sensory Characteristics | A | Supported | Instructions never rely on shape, color, or position alone (e.g., "click the green button" is not used) |
| 1.4.1 Use of Color | A | Supported | Quiz correct/incorrect uses ✓/✗ icons in addition to color; pass/fail uses explicit text labels |
| 1.4.3 Contrast (Minimum) | AA | Supported | All lesson color palette combinations meet 4.5:1 for normal text and 3:1 for large text; verified with contrast checker during palette design |
| 1.4.4 Resize Text | AA | Supported | All text uses relative units (rem/em); layout remains usable at 200% browser zoom |
| 1.4.5 Images of Text | AA | Supported | All text is rendered as HTML/CSS text, not images of text; no decorative text-as-image patterns used |
| 2.1.1 Keyboard | A | Supported | All functionality operable by keyboard: slide navigation, all quiz types (including Sequence Up/Down buttons), reveal sections, certificate modal |
| 2.1.2 No Keyboard Trap | A | Supported | Focus trapped intentionally only inside the certificate modal dialog (correct pattern); Escape key always releases the trap |
| 2.3.3 Animation from Interactions | AAA | Supported | All CSS entrance animations inside @media (prefers-reduced-motion: no-preference); content always at full opacity/position for Reduce Motion users |
| 2.4.1 Bypass Blocks | A | Supported | "Skip to main content" link is first focusable element on lesson page |
| 2.4.2 Page Titled | A | Supported | Published lesson <title> includes the lesson name from Lesson Settings |
| 2.4.3 Focus Order | A | Supported | Tab order follows visual reading order; focus moves into certificate dialog on open and returns to trigger on close |
| 2.4.4 Link Purpose | AA | Supported | Accessibility Checker flags non-descriptive link text ("click here", "read more", etc.) as warnings before export |
| 2.4.6 Headings and Labels | AA | Supported | Slide titles render as <h1>; section headings use correct hierarchy; all form inputs have associated <label> elements |
| 2.4.7 Focus Visible | AA | Supported | Native browser focus outlines preserved; custom focus styles applied to all interactive elements where native outline is removed |
| 2.5.1 Pointer Gestures | A | Supported | Sequence/Order drag-and-drop has Up/Down button keyboard alternative; no multi-point or path-based gestures required |
| 3.1.1 Language of Page | A | Supported | lang="en" on <html> in all published lessons |
| 3.3.1 Error Identification | A | Supported | FITB quiz sets aria-invalid="true" on incorrect inputs; text error message identifies the field and the problem |
| 3.3.2 Labels or Instructions | A | Supported | All quiz inputs have visible labels or legends; FITB inputs use aria-describedby to associate the question prompt with the input |
| 4.1.1 Parsing | A | Supported | Published lesson HTML is generated programmatically from structured data; no duplicate IDs or invalid nesting |
| 4.1.2 Name, Role, Value | AA | Supported | All custom interactive elements have ARIA roles, names, and state (aria-expanded, aria-pressed, aria-modal, aria-labelledby, aria-invalid) |
| 4.1.3 Status Messages | AA | Supported | Quiz feedback, score totals, and Sequence position announcements delivered via aria-live regions; no focus movement required to hear updates |
Report an Accessibility Issue
If you or a student encounters an accessibility barrier in a published lesson or in the authoring tool, please report it. Accessibility bugs are treated as high-priority issues.
Email: mary@marylebens.com
Feedback board: knowledgequeststudio.canny.io
When reporting, please include: a description of the barrier, what assistive technology you are using (screen reader name and version, browser, OS), and which feature or slide type the issue occurs on. This helps reproduce and fix the issue quickly.