Why braille‑mode typing tests make sense now
Windows 11 has quietly become a great host for braille input. Narrator added broader braille display coverage in version 22H2 and made it easier to switch drivers when you also use third‑party screen readers such as JAWS or NVDA. It also introduced an on‑screen Braille Viewer so sighted educators and testers can follow along. (support.microsoft.com)
Even more important for developers, Microsoft has begun rolling out Human Interface Device (HID) braille support in Windows 11 Insider builds, enabling true plug‑and‑play over USB (and pairing via Bluetooth on supported devices). That standardization reduces custom driver headaches and makes consistent timing and input capture realistic across displays. (learn.microsoft.com)
Background: the USB Implementers Forum published the HID braille specification in 2018 to unify how displays talk to operating systems. As more vendors and screen readers embraced it (NVDA added HID braille in 2021), cross‑device behavior has steadily converged. (usb.org)
What we’re building
A braille typing mode on a web typing test should:
- Accept Perkins‑style six‑key chords (dots 1–6) and optional 8‑dot (dots 7–8) entry.
- Offer consistent input tables (Grade 1/uncontracted, Grade 2/contracted, or 8‑dot computer braille) to match learners and curricula. (support.microsoft.com)
- Score by chords‑per‑minute (CSPM), accuracy, and a transparent error‑cost model that rewards immediate self‑correction.
Two viable capture paths exist today:
1) OS/screen‑reader translation to text (lowest friction): Your site reads text typed from the braille keyboard into an input field. Narrator/NVDA applies the chosen braille table and outputs characters.
2) Direct device events via WebHID (advanced/research): Chromium’s WebHID API can speak to uncommon HID devices, letting you timestamp raw reports and identify each chord precisely. Note that Chrome blocks access to protected usages (e.g., generic keyboard/mouse), so test against real HID‑braille usages and always gate with a user gesture. (developer.chrome.com)
Set up Windows 11 braille input (fast, reliable baseline)
For a clean, reproducible lab setup with Narrator:
1) Install Narrator’s braille feature. Open Settings > Accessibility > Narrator, choose “Use a braille display with Narrator,” then “Download and install braille.” After restart, turn on braille and add your display. (support.microsoft.com)
2) Pick matching input/output tables (Grade 1/Grade 2/8‑dot computer braille). For testing CSPM and raw chord skill, prefer 8‑dot computer braille to avoid contractions hiding multiple chords behind one character. (support.microsoft.com)
3) If you also use JAWS or NVDA, select that driver in “Braille display driver” so your display keeps working when you switch screen readers. (support.microsoft.com)
4) Use Braille Viewer to observe exactly what the student types. Start Narrator (Win+Ctrl+Enter), then toggle Braille Viewer with Narrator+Alt+B. The viewer mirrors your real display’s cell count (defaults to 40 if none is attached). (support.microsoft.com)
Notes on connectivity:
- Today’s public Narrator docs still mention USB/serial support, with Bluetooth historically limited. HID braille over USB is already landing in Insider builds, and Microsoft’s release notes explicitly call out HID braille support (with Bluetooth pairing on supported devices) as the rollout progresses—test your exact Windows 11 build before classroom deployment. (support.microsoft.com)
- Windows supports the HID‑over‑GATT (HOGP) Bluetooth profile at the OS level, which is the transport many HID braille devices use over Bluetooth. Actual Narrator support is build‑dependent, so verify on your target image. (learn.microsoft.com)
- NVDA has mature HID braille support, so if you’re building cross‑screen‑reader tests, it’s a dependable alternative. (nvaccess.org)
Designing two braille input modes
1) Six‑key mode (dots 1–6):
- Purpose: early literacy and mainstream Perkins‑style speed tests.
- Input table: Grade 1 uncontracted or 8‑dot computer braille (with dots 7–8 disabled). (support.microsoft.com)
- Scoring: define one chord as one simultaneous press/release event producing a braille cell. Compute CSPM = chords ÷ minutes.
2) 8‑dot mode (computer braille):
- Purpose: advanced users, coding, and screen‑reader power‑use where capitalization and symbol precision matter.
- Input table: 8‑dot computer braille to ensure one chord maps to one unambiguous character. (support.microsoft.com)
- Scoring: same CSPM formula; include symbol accuracy and capitalization penalties.
Measuring speed, accuracy, and learning
- CSPM (chords per minute): Timestamp at key‑up of the last dot in the chord (or device report boundary if using WebHID). Average over 15–60 seconds; report mean and 95% confidence band for repeat trials.
- Error cost: Use a two‑part model—(a) string distance (Levenshtein) between expected and produced text after all edits; and (b) a correction tax that counts extra chords for Backspace and re‑entry. Publish both so learners and educators see whether they typed carefully (low distance) or had to “fight” with many fixes (high correction tax).
- Learning curves: Store session aggregates (CSPM, distance, correction tax) per lesson and chart progress across weeks. Short, three‑minute tasks give stable signals without fatigue.
Calibrating for timing and fairness
- Character vs. chord timing: If you capture text only, your timer sees characters after screen‑reader translation. That’s fine for classroom metrics, but for research‑grade CSPM you’ll want raw HID timing so contractions don’t compress multiple chords into one character. WebHID enables this as long as your device exposes braille usages that aren’t blocked by Chrome’s protected‑usage rules. (developer.chrome.com)
- Device diversity: Favor HID‑braille‑capable models for consistent behavior. The whole point of the HID braille standard is plug‑and‑play across vendors and OS versions. (usb.org)
- Screen reader parity checks: Validate with Narrator (Windows 11) and NVDA (HID braille since 2021) using identical input/output tables and the same passages. (nvaccess.org)
- Observer tooling: Keep Braille Viewer pinned for sighted QA; it mirrors the connected device’s cell count and is ideal for resolving “my dots looked right but the character was wrong” reports. (support.microsoft.com)
Practical setup tips
- Standardize tables: For timed tests, start with 8‑dot computer braille to eliminate contractions, then add Grade 1 and Grade 2 tracks as distinct curricula so scores remain apples‑to‑apples. (support.microsoft.com)
- Turn off autocorrect in your input fields and disable smart quotes—these can mutate characters after the fact and inflate error cost.
- Keep audio minimal during tests. Narrator and NVDA both let users reduce typing echo so speech doesn’t mask timing; use the Braille Viewer for monitoring instead. (support.microsoft.com)
- If you’re piloting on Insider builds, record the exact Windows build in your results; HID braille and Bluetooth pairing behavior is in active rollout. (neowin.net)
Validation: does your scoring generalize?
- Cross‑display battery: Test on at least three HID‑capable displays from different vendors and at two cell widths (e.g., 20 and 40/80 cells). The HID braille spec exists to keep these consistent—use that to your advantage. (usb.org)
- Cross‑reader run: Repeat with Narrator and NVDA. NVDA’s HID braille path is mature; if your CSPM and error‑cost distributions are similar between readers, your test is robust. (nvaccess.org)
Known gotchas (and how to avoid them)
- Bluetooth inconsistencies: Public Narrator docs historically limited braille to USB/serial; HID‑braille Bluetooth pairing is emerging via Insider builds. If pairing fails or timing looks erratic, switch to USB for the test session. (support.microsoft.com)
- Contraction confusion: If learners use Grade 2 but your answer key expects literal characters, you’ll under‑count chords and over‑penalize. Match the table to the lesson—or prefer 8‑dot for timed drills. (support.microsoft.com)
- Protected usages with WebHID: If your display also enumerates as a standard keyboard, browser access to that collection may be blocked. Filter for the braille interface and request permission only after a user gesture. (developer.chrome.com)
The bottom line
Between the industry’s 2018 HID braille standard, NVDA’s long‑standing support, Narrator’s expanded device coverage and Braille Viewer, and the ongoing rollout of HID braille in Windows 11 Insider builds, braille‑mode typing tests are finally practical—and portable across hardware. Build for 8‑dot first, measure CSPM and error cost transparently, and validate across Narrator and NVDA for confidence in real‑world classrooms and training labs. (usb.org)
