Compare ways of navigating

Linear and spatial models

Keyboard commands and touch swipes often expose objects as a sequence. Touch exploration also reveals spatial relationships on a screen. A product can therefore have more than one meaningful navigation path. When several models are supported, each path needs a coherent order and must reach all required controls.

• A card grid can be read as a sequence from the first card to the last.
• A touch user may expect an item beneath their finger to match its visual location.
• A braille user may move through text at word or character level.
• A web-view user may cross from native app controls into browser-backed content.
• All users need context when navigation crosses a section boundary.

Focus is the user's position

Focus tells the product which object receives input. Screen readers can also maintain a reading position or virtual cursor for exploring content. These positions are related but not always identical. Product code should move focus only when the task requires it, and the destination should explain what changed.

• Opening a dialog should place focus at a useful position inside it.
• Closing the dialog should normally return focus to the control that opened it.
• Adding content should not move focus without a clear reason.
• Removing the focused item requires a predictable new destination.
• A route change needs a clear starting point and an announcement of the new context.

Compare one task across inputs

Consider choosing a saved payment method in a checkout flow. A keyboard user may jump to a heading and tab to a saved-card control. A touch user may explore the screen or swipe through cards. A braille user may search headings and read compact labels. A user inside an embedded web view may cross between native app controls and browser-backed content. They use the same content, but each path creates different risks.

• Keyboard order can differ from visual order.
• Swipe order can include hidden or duplicate objects.
• Touch exploration can find an unlabeled icon.
• Braille output can make verbose repeated labels inefficient.
• A web-view boundary can change focus, announcements, or recovery behaviour.

Design for orientation and recovery

Users need to know where they are, what is available, and how to return after a mistake. Headings, landmarks, page titles, selected states, position information, and predictable focus all support orientation. Recovery controls such as Back, Cancel, Close, and Undo need clear names and consistent behaviour.

Avoid common testing shortcuts

Tabbing through a page is not the same as using a screen reader. Tab normally reaches interactive controls, while screen reader navigation can also reach headings, text, lists, tables, and landmarks. Testing only with swipe gestures can miss spatial touch exploration, and testing only with speech can miss braille concerns. Select commands that represent the supported input and the task, then observe both the navigation path and the information available at each step.