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.
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.
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
The system moves focus automatically through groups and controls.
The person activates a switch to select the highlighted target.
Some users use one switch for select and timed scanning; others use two switches for next and select.
Text entry may happen through an on-screen keyboard, prediction, Morse, or stored phrases.
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.
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>
);
}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
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.