Command Palette

Search for a command to run...

Accessibility use case

Switch Control and Scanning

Switch Control access guidance for Tamil DS

How people use switches to navigate, supported by WCAG 2.4.3 (Focus Order) and WCAG 2.1.2 (No Keyboard Trap).

Detailed guidance for real users, assistive technology, component behavior, testing, and release checks.

Who this supports

People with significant motor impairments who may operate a switch with a hand, head, cheek, foot, breath, or another reliable movement.

Assistive technology

iOS Switch ControlAndroid Switch AccessAdaptive switchesSip-and-puffScanning keyboards

Primary risk

Dense interfaces and missing focus targets make each selection slow, tiring, and error-prone.

Roving Switch Scanning Path

1. Header Navigation

Contains Home, Docs, About

2. Service Forms Group

Form inputs & fields

3. Action Toolbar

Submit, Save, Clear

Metrics

4 Stops

Perfect! Focus scans components dynamically using nested sections.

Active scan index: 1

Real user scenario

A person books an appointment using a single switch. The focus highlight scans across sections, then controls, then options. They wait for the correct target and activate it. If the page has too many tiny controls or a modal steals focus unexpectedly, the task becomes exhausting.

How people use this access method

1

The system moves focus automatically through groups and controls.

2

The person activates a switch to select the highlighted target.

3

Some users use one switch for select and timed scanning; others use two switches for next and select.

4

Text entry may happen through an on-screen keyboard, prediction, Morse, or stored phrases.

5

Good grouping reduces the number of scans needed to reach important actions.

Design requirements

These requirements are product requirements, not optional polish. If a Tamil DS component or page breaks one of these rules, users may be blocked even when the visual interface looks finished.

Group related controls so scanning can move by region, not only item by item, maintaining a logical WCAG 2.4.3 (Focus Order).

Ensure users can scan in and out of all components without getting stuck (WCAG 2.1.2 No Keyboard Trap).

Keep touch targets large and separated.

Reduce unnecessary controls in the active task path.

Avoid automatic focus changes that interrupt scanning.

Provide undo and back because accidental selection is common.

Use predictable order: header, content, field, helper, action.

Avoid time-limited steps unless there is a pause or extend option.

Persist partially completed forms and allow resume.

Accessible code implementation

Use this correct, semantic React/HTML/CSS implementation pattern as a template when building or styling components for this specific access method:

// Roving Tabindex for switch scanning-friendly Tab panels
import React, { useState } from "react";

export function ScanningRovingTabs({ tabs }) {
  const [activeIndex, setActiveIndex] = useState(0);

  const handleKeyDown = (index, e) => {
    let nextIndex = index;
    if (e.key === "ArrowRight") nextIndex = (index + 1) % tabs.length;
    if (e.key === "ArrowLeft") nextIndex = (index - 1 + tabs.length) % tabs.length;
    
    if (nextIndex !== index) {
      setActiveIndex(nextIndex);
      // Focus the newly active tab programmatically
      document.getElementById(`tab-trigger-${nextIndex}`)?.focus();
    }
  };

  return (
    <div className="border border-border rounded-md bg-card p-4">
      {/* Tablist grouping reduces scanning stops to 1 instead of N triggers */}
      <div role="tablist" aria-label="Benefits categories" className="flex border-b border-border mb-4">
        {tabs.map((tab, i) => (
          <button
            key={tab.id}
            id={`tab-trigger-${i}`}
            role="tab"
            aria-selected={activeIndex === i}
            // Only the active item is in the natural tab order (tabIndex=0)
            tabIndex={activeIndex === i ? 0 : -1}
            onClick={() => setActiveIndex(i)}
            onKeyDown={(e) => handleKeyDown(i, e)}
            className={`px-4 py-2 text-sm font-semibold border-b-2 -mb-px transition-all focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-primary ${
              activeIndex === i ? "border-primary text-foreground" : "border-transparent text-muted-foreground"
            }`}
          >
            {tab.label}
          </button>
        ))}
      </div>
      
      <div role="tabpanel" id={`tab-panel-${activeIndex}`} className="text-sm text-muted-foreground p-2">
        {tabs[activeIndex].content}
      </div>
    </div>
  );
}
Technical breakdown: For switch and scanning users, every interactive control represents a scanning stop. Having dozens of buttons in a toolbar can make the navigation cycle take minutes. By implementing a 'roving tabindex' (where only one tab in a group is focusable using Tab, and navigation between tabs uses Left/Right Arrow keys), we reduce the entire tabs widget to a single scanning stop, greatly reducing user exhaustion.

Component behavior implications

Accessibility becomes real at component level. The same page may pass content review but fail when dialogs, forms, menus, cards, or status messages do not expose the right behavior.

Radio groups and lists should support arrow-key or roving-focus behavior cleanly.

Carousels must not auto-advance while a switch user is scanning.

Dialogs need a small, meaningful focus order and a clear close control.

Date pickers need direct entry alternatives because grid scanning is expensive.

Menus should not close unexpectedly after accidental movement.

Search and filtering should avoid excessive live-updating that resets focus.

Testing script

Run this script before release. Automated checks are useful, but they do not replace trying the actual access method and completing a real task from start to finish.

Use keyboard Tab to approximate scanning order.

Count how many focus steps are needed to reach the primary action.

Test with large text and mobile layout.

Open overlays and confirm the focus order remains short and predictable.

Try making an accidental selection and recovering without starting over.

Check whether carousels, timers, and auto-updates can be paused.

Complete one realistic task using only keyboard and visible focus.

Common failures and fixes

Failure

Too many small controls in one dense toolbar

Group controls, expose only task-relevant actions, and use menus when they reduce scanning cost.

Failure

Focus jumps after every selection

Keep focus near the user's current task unless a deliberate navigation occurred.

Failure

Date picker requires scanning 30 cells

Offer typed date entry and quick month/year controls.

Failure

Timeout expires during scanning

Provide pause, extend, save draft, or no-timeout alternatives.

Tamil public-service context

Tamil DS must work for Tamil-first, English-first, and bilingual users across phones, desktops, kiosks, classrooms, offices, and public-service counters. These notes keep the guidance connected to local product reality.

Public-service flows should avoid long multi-step forms without save and resume.

Tamil labels may wrap to two lines; target size and spacing must remain stable.

Scanning users benefit from predictable section labels such as Applicant details, Address, Documents, Review.

Release checklist

Scanning order is short and logical.

Controls are large and separated.

Automatic movement can be paused.

Undo and back are available.

Forms preserve progress.