Braille Keyboard Access

What a braille keyboard is

A braille keyboard is an input method built around the six-dot braille cell. Instead of pressing a separate key for every alphabet character, the person presses a combination of dot keys at the same time. This combination is called a chord. The device may be a dedicated Perkins-style keyboard, a refreshable braille display with input keys, or a phone feature such as braille screen input.

The important design-system lesson is simple: a braille user does not experience a page as a screenshot. They experience it as focused objects, accessible names, roles, values, state, editable text, headings, landmarks, and announcements. The visual layer still matters, but the semantic layer is what becomes tactile, directly enforcing WCAG 4.1.2 (Name, Role, Value).

The six-dot mental model

The standard braille cell has two columns and three rows. Dots 1, 2, and 3 are on the left. Dots 4, 5, and 6 are on the right. A keyboard maps each dot position to a physical key. The user presses the needed dot keys together, then releases them to commit a character.

How a person actually uses it

Typing examples

The examples below are uncontracted English braille examples. Real users may use grade 1, grade 2 contracted braille, eight-dot computer braille, Tamil braille, or a local braille table configured in their screen reader. The product should not assume only one braille table.

Refreshable braille display behavior

A refreshable braille display is not just a keyboard. It is also an output device. A row of small pins raises and lowers to form tactile braille cells. The person reads the current line through touch, pans left or right for more text, and uses routing keys to place the cursor. This output relies heavily on WAI-ARIA Live Regions to meet WCAG 4.1.3 (Status Messages), ensuring dynamic updates push tactile output without stealing keyboard focus.

// Tactile routing text field in React
import React, { useState, useId } from "react";

export function TactileRoutingTextField({ label, labelTa }) {
  const id = useId();
  const [value, setValue] = useState("");
  const [cursorPos, setCursorPos] = useState({ start: 0, end: 0 });

  const handleSelection = (e) => {
    // Expose cursor positions explicitly so refreshable braille displays
    // raise dot indicators around the focused caret selection block
    setCursorPos({
      start: e.currentTarget.selectionStart || 0,
      end: e.currentTarget.selectionEnd || 0,
    });
  };

  return (
    <div className="flex flex-col gap-2">
      <label htmlFor={id} className="text-sm font-bold">{label}</label>
      <input
        id={id}
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
        onSelect={handleSelection}
        className="rounded-md border border-border px-3 py-2 text-sm focus:outline-none focus:ring-2 focus:ring-primary"
      />
      <div className="text-[10px] text-muted-foreground">
        Caret routing cursor indexes: {cursorPos.start} - {cursorPos.end}
      </div>
    </div>
  );
}

Design-system requirements

Common mistakes and fixes

Testing checklist

If you do not have a physical braille display, you can still catch many problems with NVDA, VoiceOver, TalkBack, browser accessibility trees, and keyboard-only testing. For release confidence, test the flow with a real display and a real braille user whenever possible.

What good support feels like

Good braille support feels quiet, predictable, and precise. The user knows where focus is, what each control does, whether a value changed, where the cursor is inside text, and what to do next. The page does not need special treatment or a separate braille mode. It needs strong semantics, stable focus, useful announcements, and components that respect native behavior.