Command Palette

Search for a command to run...

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.

Who this supports

Blind users, motor-impaired users, power users, developers, people with broken pointing devices, and anyone who cannot use a mouse at the moment.

Assistive technology

Hardware keyboardOn-screen keyboardAlternative keyboardsSwitch keyboard emulation

Primary risk

A UI can appear usable with a mouse while trapping, hiding, skipping, or losing keyboard focus.

Interactive Focus Matrix

Press 'Tab' key inside sandbox

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

1

Tab moves through focusable controls in DOM order.

2

Enter and Space activate controls depending on element type.

3

Arrow keys navigate inside composite widgets such as tabs, sliders, radio groups, menus, and listboxes.

4

Escape closes temporary UI such as dialogs and popovers.

5

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.

Never remove focus outlines without replacing them with an equally visible indicator (WCAG 2.4.7 Focus Visible).

Ensure focused elements are never completely hidden by sticky headers or overlays (WCAG 2.4.11 Focus Not Obscured).

Use semantic controls so native keyboard behavior works automatically.

Keep focus order aligned with layout and task sequence.

Skip decorative or disabled elements in the tab order.

Provide skip links for repeated navigation.

Trap focus inside modal dialogs and restore it on close.

Support Escape for dismissible overlays.

Document custom keyboard behavior in component examples.

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>
  );
}
Technical breakdown: This dialog implements a rigid focus trap. It queries focusable items upon open, places the initial focus inside the dialog, intercepts the Tab key to wrap focus back to the top/bottom of the modal, and handles the Escape key to close the modal. This guarantees a keyboard-only user can never accidentally focus background content while the overlay is open.

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

Failure

Focus ring is clipped by overflow hidden

Use ring offsets, inner outlines, or enough padding around focused controls.

Failure

Custom widget supports click but not keyboard

Use native elements or implement the full expected keyboard pattern.

Failure

Focus goes behind a modal

Use focus trapping and inert background content while the modal is open.

Failure

Tab order follows CSS layout instead of DOM meaning

Reorder DOM to match the task instead of relying on positive tabindex.

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.