Command Palette

Search for a command to run...

Accessibility use case

Screen Reader Navigation

Screen Reader access guidance for Tamil DS

How blind and low-vision people navigate pages through headings, landmarks, links, controls, labels, states, and announcements instead of visual layout, grounded in W3C WCAG 1.3.1 (Info and Relationships) and WCAG 4.1.2 (Name, Role, Value).

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

Who this supports

Blind users, many low-vision users, and people who prefer audio output when reading dense or unfamiliar interfaces.

Assistive technology

NVDAJAWSVoiceOverTalkBackNarratorBraille display output

Primary risk

A screen can look complete while the accessibility tree is empty, unordered, mislabeled, or impossible to operate.

Screen Reader Announcement Simulator

Simulated UI Elements

Apply / விண்ணப்பிக்கவும்Button
Show details / விவரங்கள்Trigger
Enter card number...Input

📣 Speech: Screen Reader active. Navigate items below to hear speech announcements.

Click any simulated UI element on the left to see how a screen reader reads it.

Real user scenario

A person opens a Tamil Nadu public-service form to renew an ID card. They jump by heading to find the correct section, move through fields with Tab, listen for labels and error messages, review confirmation details, and submit without seeing the visual card layout. If the page has generic links, unlabeled icons, or a toast that is not announced, the person loses the task.

How people use this access method

1

The screen reader builds an audio model from semantic HTML, ARIA labels, roles, states, and live regions.

2

The person moves by landmarks, headings, links, form controls, lists, tables, and rotor or quick-navigation commands.

3

When focus lands on a control, the screen reader announces its accessible name, role, state, value, and helper text.

4

Dynamic changes need live regions or focus movement. Silent updates are not available to the person.

5

The person may combine speech with a braille display, so names and state text must be concise and stable.

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.

Every page must have a unique, descriptive <title> (WCAG 2.4.2 Page Titled).

Provide descriptive alt text for informative images and use empty alt='' for decorative images (WCAG 1.1.1 Non-text Content).

Ensure logical structure via semantic HTML and ARIA landmarks to satisfy WCAG 1.3.1 (Info and Relationships).

Use real headings in a logical order. Do not style ordinary text to look like a heading.

Give every input a visible label and connect helper text and errors programmatically (WCAG 3.3.2 Labels or Instructions).

Use real buttons for actions and real links for navigation.

Name icon-only controls with action-specific labels such as Close dialog or Download receipt to satisfy WCAG 4.1.2 (Name, Role, Value).

Keep focus order aligned with the reading order and visual task order.

Announce loading, success, error, and status changes with appropriately scoped live regions (WCAG 4.1.3 Status Messages).

Use table headers, captions, and summaries when data is tabular.

Avoid repeated, noisy announcements that make the person listen to the same content again.

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:

// Screen Reader-compliant Form Field in React
import React, { useId } from "react";

export function AccessibleInputField({ label, labelTa, error, helperText, ...props }) {
  const id = useId();
  const helperId = `${id}-helper`;
  const errorId = `${id}-error`;

  return (
    <div className="flex flex-col gap-1.5 w-full">
      {/* Label linked via htmlFor */}
      <label htmlFor={id} className="text-sm font-semibold text-foreground">
        {label} 
        {labelTa && <span className="block mt-0.5 text-xs text-muted-foreground font-tamil" lang="ta">{labelTa}</span>}
      </label>

      {/* Input wired with helper text and error state */}
      <input
        id={id}
        aria-describedby={`${helperText ? helperId : ""} ${error ? errorId : ""}`.trim() || undefined}
        aria-invalid={!!error}
        className="rounded-md border border-border px-3 py-2 text-sm focus-visible:ring-2 focus-visible:ring-primary focus-visible:outline-none"
        {...props}
      />

      {/* Helper text */}
      {helperText && (
        <p id={helperId} className="text-xs text-muted-foreground leading-relaxed">
          {helperText}
        </p>
      )}

      {/* Error message with live announcement */}
      {error && (
        <p id={errorId} className="text-xs text-destructive font-semibold" aria-live="assertive">
          {error}
        </p>
      )}
    </div>
  );
}
Technical breakdown: This React code leverages WCAG 2.1 AA best practices by pairing an explicit <label> connected to the <input> via the htmlFor attribute. It uses aria-describedby to link helper text and error messages, ensuring they are announced when the input receives screen reader focus. Crucially, the error message has aria-live="assertive" so that any dynamic validation error is spoken immediately to the user without needing them to shift focus.

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.

Dialog, Sheet, Popover, and Dropdown must trap or manage focus correctly and restore focus when closed.

Toast and Alert must expose status through live regions when the message matters.

Tabs need keyboard navigation and clear selected state.

Forms need field-level errors, summary errors, and aria-describedby wiring.

Cards should not be clickable divs. Use links or buttons with meaningful names.

Data visualization must include a text summary and data table fallback.

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.

Run through the page with NVDA and Firefox or VoiceOver and Safari.

Navigate by headings and confirm the page outline makes sense.

Tab through every control and verify the spoken name matches the visible purpose.

Trigger validation errors and confirm the field and error are announced together.

Open and close overlays with keyboard commands and confirm focus returns correctly.

Check Tamil and English mixed labels with correct lang attributes where needed.

Confirm no important update depends only on color, animation, or visual position.

Common failures and fixes

Failure

Clickable cards implemented as divs

Use a real anchor or button and make the accessible name describe the destination or action.

Failure

Form fields use placeholder text as the only label

Add persistent visible labels and connect helper or error text with aria-describedby.

Failure

Modal opens but focus stays behind the overlay

Move focus into the dialog, keep it there while open, and restore focus on close.

Failure

Status changes appear visually but are silent

Use role=status, role=alert, or a scoped live region depending on urgency.

Failure

Complex SVGs lack accessible names

Provide a <title> element inside the SVG and reference it via aria-labelledby.

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.

Tamil labels can be longer than English labels, so the accessible name should remain meaningful after wrapping.

Government pages often mix English codes with Tamil descriptions; mark language changes where pronunciation matters.

Do not hide official terms behind icons because a screen-reader user may scan controls out of context.

Release checklist

Heading outline is valid.

Every interactive element has a clear name, role, value, and state.

All overlays manage focus.

All form errors are announced.

Dynamic status changes are available to assistive technology.