Making Interactive Tests Accessible to Keyboards and Screen Readers

A student knows the answer but cannot select a hover-only card. Another hears options without their question. The test then measures interface barriers instead of knowledge. Assessment loses meaning when interaction prevents the intended demonstration.

Accessibility combines technical implementation and instructional decisions: correct elements, clear names, predictable keyboard behavior, status messages, wording, timing, and answer formats. Check complete attempts from instructions to submission and feedback. One accessible button does not establish full accessibility.

This practical route for creators, administrators, and developers uses W3C WAI materials without replacing assessment of all applicable WCAG criteria. Complex components need specialist and assistive-technology user testing. Tab navigation alone cannot prove screen-reader or other accessibility.

Define What the Task Measures

Specify recall, comparison, sequencing, or reasoning before choosing interactions. Replace decorative dragging with simpler formats where meaning remains. Spatial actions need separate accessible-representation analysis. Avoid complex gestures merely because templates look attractive.

Distinguish professional requirements from interfaces. Risk classification need not require precise cursor movement, nor terminology knowledge fast popup reading. Alternatives should measure the same competence under agreed criteria, without quietly making assessments easier.

Use Familiar Controls Where Appropriate

Native HTML controls with correct labels often suit standard answers. Custom cards need roles, states, focus, and keyboard behavior. One ARIA attribute does not create behavior. Developers must test complete interactions; authors should require custom components only with learning needs and maintenance capacity.

The WAI labeling guidance explains associations between names and controls. Assistive technology needs clear field and option names; adjacent visible text may not create that association. Button names should distinguish submission from navigation and saving.

Keep Questions Associated With Answers

Logically group related radio buttons. WAI describes grouping with fieldset and legend and other appropriate mechanisms. Participants should understand questions, choice types, and option groups without relying on visual borders or proximity.

Check long questions and repeated yes/no options. Speech needs context without repeating enormous prompts unnecessarily. Use semantics and real behavior checks. Ask users which task their current selection belongs to and observe context recovery without sight.

Complete the Test Without a Mouse

Begin at sign-in, not an active question. Find instructions, start, navigate, change answers, and finish. Record keys and stopping points. The WCAG keyboard criterion concerns keyboard-operable functionality with defined exceptions; check every necessary function in the actual attempt.

Do not require Tab alone. Standard patterns use other keys; radio groups usually support arrows. APG describes the relevant pattern. Keep behavior predictable and documented. Differences need justification, accessible instructions, and user checks. Ordinary answers should not require technical documentation.

Make Focus Visible and Logical

Keyboard users need visible location. Keep focus indicators and meaningful order through instructions, fields, hints, and actions. Unexpected jumps divert attention. Check popups, fixed panels, and explanations that may obscure active elements.

After question changes, communicate what opened and where content begins. Avoid leaving focus on removed or invisible elements. Implementation needs technical decisions. Define expected understanding, navigation, and permitted backtracking in plain language, then test in context.

Check Name, Role, and State With a Screen Reader

Communicate purpose and state alongside text. Distinguish buttons, fields, and selected options beyond color or decorative icons. Authors define intended information; specialists check semantics. Investigate unusual announcements before declaring errors.

Record browser, operating system, and screen reader combinations. One setup proves little elsewhere. Define justified supported-environment checks and limitations. Beginners should learn navigation or work with specialists to avoid confusing inexperience with defects or missing real barriers.

Make Errors Correctable

Identify missing required answers and navigation to them. Red borders alone are insufficient. WAI user notification guidance covers accessible success and error messages. Distinguish technical validation, saved-data status, and assessment feedback.

Preserve valid answers when something is missing. Explain saved attempts and next steps. Network failures need confirmation rather than false completion. Provide clear support routes and minimal required details without demanding public answer disclosure.

Review Time Limits

Justify timers through learning goals and assess applicable requirements. WCAG 2.2.1 describes time-limit controls and exceptions. Avoid one simplified rule for every test. Determine what speed measures, necessary accommodations, and approval responsibility before assessment so participants receive consistent conditions.

Check accessible expiry warnings, interruptions from second-by-second announcements, and saved-answer clarity. Extensions must also be accessible. Buttons alone do not help if messages vanish before discovery or focus remains trapped elsewhere.

Provide Dragging Alternatives

Consider move buttons, position selection, or equivalent accessible interactions for sorting and matching. WCAG criterion 2.5.7 concerns single-pointer alternatives where dragging is not essential; keyboard access needs separate testing. Neither alone proves complete accessibility.

Communicate order, movement results, corrections, and established pairs beyond drawn lines. Simpler formats may convey state more reliably, while preserving difficulty rather than substituting easier prompted tasks.

Address Images, Formulas, and Media

Chart descriptions must provide necessary information without revealing answers. Avoid decorative noise and missing meaningful images. Test formulas, table structures, and assistive technology behavior. Alternatives must retain key data and assessed skills.

Determine whether perceiving audio or video signals is essential to competence. Otherwise provide accessible content. If essential, seek subject-specific professional decisions about accommodations, explain conditions beforehand, and provide needs discussions before attempts.

Check Final Submission

Explain irreversible consequences, including completion, no return, and review. Distinguish drafts from final submission. Check confirmation dialogs and focus after cancellation. Participants need control without relying on button placement or tiny notes.

Show confirmed status and next steps. Explain delayed results, answer review, and retries, testing these routes too. Without confirmation, provide reconciliation processes rather than place all proof burdens on students.

Organize Team Fixes

Separate content, administrative, and development tasks: instructions and formats, settings, semantics and behavior. Test actual WeStudy task types without assumed capabilities. Assign external-component owners and accessible temporary routes preserving goals.

Record reproduction steps, expected and actual results, environments, and student impact. Retest fixes and related transitions, since improved forward focus may break backtracking. Define acceptance owners and verify learning experiences before closing tasks.

Examine a Complete Hypothetical Defect

Imagine five questions with explanations after answers. Visual checks pass, but keyboard use reveals continuation buttons elsewhere while focus stays on previous options. Students cannot tell whether answers were accepted. This illustrates checking state changes rather than only initial appearances.

Record actions, input methods, and expected messages. Authors check explanation and next-task accessibility; developers check focus and announcements. Retest correct and incorrect answers, backtracking, and completion, because branches may use different components.

If fixes cannot precede assessment, agree on equivalent exercises or postponed attempts considering goals and consequences. Do not make students find someone with a mouse. Such assistance undermines independent demonstration and may expose confidential answers.

After the cohort, trace causes. Shared-template defects require checking affected tests; isolated settings need acceptance checks. Match scope to evidence, fix dependencies, and make recurrence detectable without unjustified environment-wide controls.

Prepare Useful User Testing Tasks

Give goals rather than step-by-step keys. Ask participants to start, answer, and revise before submission, observing discovery. Record moderator assistance: prompted completion is not independent barrier-free use.

Agree on suitable equipment and breaks. Do not force experienced users onto unfamiliar assistive technology for identical computers. Record usual tools and reproducible environments to distinguish general defects from specific incompatibilities and clarify supported configurations.

Ask neutral questions about actions, selected answers, and completion rather than request design approval. Collect only necessary data. Recordings need agreed access and procedures; technical fixes usually require steps and outcomes rather than personal details.

Keep a Short Test Acceptance Procedure

Before cohorts, authors check goals, wording, and alternatives; administrators check settings and journeys; specialists verify components and known fixes. Reuse established patterns while reviewing new interactions and environmental changes. Record checks, owners, and versions before assessment.

Define blockers and agreed accessible workarounds according to impact. Inability to select or submit differs from awkward but clear labels. Prioritize fair demonstrations under shared learning criteria rather than ease of fixing.

Rehearse Before Actual Assessment

Provide low-stakes practice with every interaction. Students can check equipment and ask early. Rehearsal does not shift responsibility: fix known barriers regardless of complaints. Identify incompatibilities before completion or progression decisions are affected.

Rehearse in the same agreed WeStudy environment as real attempts. Check support contacts and failure responses. Accessible tests enable varied interaction. Start with goals, check semantics, keyboards, messages, and completion, and validate through realistic scenarios so interfaces support rather than determine results.

Keep a verified example for future authors with scope limitations, showing which properties are confirmed and what requires reassessment after component or setting changes.

Sources

1. WAI: Form Labels.

2. WAI: Grouping Related Controls.

3. WAI APG: Radio Group Pattern.

4. WCAG 2.2: Keyboard.

5. WAI: User Notifications.

6. WCAG 2.2: Timing Adjustable.

7. WCAG 2.2: Dragging Movements.