An attached keyboard requires full keyboard navigation

What it is

Once a physical keyboard is attached to a tablet, hands leave the glass and rest on keycaps, and the primary input becomes keys. Full keyboard navigation means every tappable target can then be reached, activated, and left from the keyboard: Tab through controls, arrows through grids and lists, Enter to activate, Escape to dismiss. Wiring only text fields to the keyboard, while buttons still require a tap, leaves one hand typing and the other reaching for the screen, which throws away half of what the keyboard was for. Whether shortcuts share desktop names, and how the viewport changes when the software keyboard dismisses, are other problems.

Why it happens

Touch selects with a finger; the coordinate is the contact. A keyboard selects with focus; the coordinate is a position in a control sequence. Attaching a keyboard swaps the selection device, so “tappable” has to be translated into “focusable.” Invisible focus, a scrambled order, or custom widgets left out of the sequence leave keyboard users unable to find themselves on the screen. Tablets still take touch, and the two devices alternate: someone may arrow to a list and then tap a row. Focus and touch selection must share one object, or A is tapped while the key caret is still on B. Attached keyboards often include a trackpad, so a pointer may appear. Keyboard navigation still has to be complete: not everyone uses the trackpad, and pointer-free reachability is the floor for this entry.

Studying it

Attach a keyboard, forbid touch (or keep hands off the glass), and walk a main path that includes a list, a form, a dialog, and a menu. Compare “only fields are focusable” with “every interactive control is focusable and the order matches visual layout.”

Independent variables: whether custom widgets join the focus sequence, whether a focus ring is visible, whether arrow keys move inside a grid. Dependent variables: task completion, Tab count, mid-task reaches to the screen, lost focus.

A reach to the screen is a failure signal: the keyboard path broke there. Do not treat a desktop-browser accessibility score as a tablet score—WebView and native controls mixed in a tablet shell lose focus between two trees. Run a separate condition when a trackpad is available, so pointer moves are not counted as keyboard completion.

Where it stops holding

Read-only paging can live on Space and arrows; not every decorative icon needs focus. A game that treats the whole screen as a touch region should map the attached keyboard onto its own bindings rather than forcing a Tab ring. With no keyboard attached, the focus ring can stay off so it does not interfere with touch; once a keyboard is present, the ring must appear on the first Tab. Screen-reader users may walk focus without an attached keyboard; that is an assistive path that overlaps this mode without sharing its trigger.

Applying it

• When a keyboard connects, enable full focus traversal: buttons, tabs, rows, switches, and menu items take focus; custom widgets implement focus and activation.
• Walk focus in visual reading order, not creation order. Use arrows inside a grid or toolbar; Tab only enters and leaves that group.
• Keep the focus ring contrasted, and point it at the same object as touch selection.
• Verify by attaching a keyboard and walking from launch to submit without touching the glass. Any step that requires a tap names the control that still needs to join the sequence.

Related

• Within the group: K3.04.2 Dismissing the software keyboard changes the visible area · K3.04.3 Shortcuts should match the desktop ones people already know
• Adjacent: C6.22 Focus Order and Keyboard Navigation · K2.03 Menu Bar · K2.04 Desktop Shortcut Systems
• Search terms: keyboard navigation · focus order · attached keyboard