Accessibility use case
Keyboard Only Access
Keyboard Only access guidance for Tamil DS
How people complete every interaction without a pointer, addressing WCAG 2.4.7 (Focus Visible) and WCAG 2.4.11 (Focus Not Obscured).
Detailed guidance for real users, assistive technology, component behavior, testing, and release checks.
Interactive Focus Matrix
Keyboard Tab Traversal Simulation
Real user scenario
A user navigates a dashboard with Tab, opens a filter popover, selects options with arrow keys, presses Escape to close it, reviews table rows, and downloads a report. If focus disappears after the popover closes, the user has to restart the page mentally.
How people use this access method
Tab moves through focusable controls in DOM order.
Enter and Space activate controls depending on element type.
Arrow keys navigate inside composite widgets such as tabs, sliders, radio groups, menus, and listboxes.
Escape closes temporary UI such as dialogs and popovers.
A visible focus indicator tells the person where they are.
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:
// Custom Modal Dialog with Focus Trap in React
import React, { useEffect, useRef } from "react";
import { X } from "lucide-react";
export function AccessibleDialog({ isOpen, onClose, title, children }) {
const dialogRef = useRef(null);
useEffect(() => {
if (!isOpen) return;
// Focus first focusable item on open
const focusable = dialogRef.current?.querySelectorAll(
'button, [href], input, select, textarea, [tabindex="0"]'
);
const first = focusable?.[0];
first?.focus();
// Trap focus inside modal boundaries
const handleKeyDown = (e) => {
if (e.key === "Escape") onClose();
if (e.key !== "Tab") return;
const active = document.activeElement;
const last = focusable?.[focusable.length - 1];
if (e.shiftKey && active === first) {
last?.focus();
e.preventDefault();
} else if (!e.shiftKey && active === last) {
first?.focus();
e.preventDefault();
}
};
window.addEventListener("keydown", handleKeyDown);
return () => window.removeEventListener("keydown", handleKeyDown);
}, [isOpen, onClose]);
if (!isOpen) return null;
return (
<div className="fixed inset-0 z-50 flex items-center justify-center bg-black/60 backdrop-blur-xs">
<div
ref={dialogRef}
role="dialog"
aria-modal="true"
aria-labelledby="dialog-title"
className="w-full max-w-md rounded-md bg-card p-6 shadow-xl border border-border"
>
<div className="flex items-center justify-between border-b border-border pb-3 mb-4">
<h3 id="dialog-title" className="text-lg font-semibold">{title}</h3>
<button onClick={onClose} aria-label="Close dialog" className="rounded-full p-1 hover:bg-muted focus-visible:ring-2 focus-visible:ring-primary">
<X className="size-4" />
</button>
</div>
<div>{children}</div>
</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.
Button, Link, Checkbox, RadioGroup, Select, Tabs, Slider, Dialog, and Menu components must own keyboard behavior.
Custom card links should be anchors, not divs with click handlers.
ScrollArea should not trap focus inside a scroll container.
Carousels need keyboard controls and pause behavior.
Toolbars need a predictable focus pattern.
Toast actions must be reachable before disappearing or have a persistent alternative.
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.
Unplug the mouse or avoid touching it during the test.
Start at the browser address bar and Tab through the full page.
Confirm focus is always visible.
Open and close every overlay with keyboard only.
Operate every form control with Enter, Space, arrows, Home, End, and Escape as appropriate.
Check skip link behavior.
Complete a full submit or purchase-like task.
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 kiosk users may depend on hardware keyboards when touch screens are unreliable.
Tamil text wrapping should not push focused buttons partly outside the viewport.
Keyboard paths are essential for government and education contexts where assistive hardware varies widely.
Release checklist
Every interaction works without a pointer.
Focus is always visible.
Overlays trap and restore focus.
Composite widgets use expected key behavior.
No keyboard traps exist.