accessibleFoundations

Accessibility

Accessibility is fundamental to the UX4G Design System 3.0. Every component, pattern, and guideline is designed to meet WCAG 2.1 Level AA standards, ensuring government digital services are accessible to all citizens of India.

Sections

WCAG Level

25+

Toolkit Features

100%

Keyboard Operable

Important

This page documents the accessibility standards, patterns, and toolkit built into the UX4G Design System 3.0. The accessibility toolkit provides user-facing controls but does not replace the need for proper semantic HTML, color contrast, and screen reader testing throughout your site.

Accessibility Principles

Core principles guiding accessibility implementation in UX4G

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Sufficient color contrast for text and interactive elements
Text alternatives for non-text content
Captions and alternatives for multimedia
Content adaptable without loss of information

Operable

User interface components and navigation must be operable by all users.

All functionality available via keyboard
Sufficient time for users to read and interact
Navigation mechanisms are clear and consistent
No content that could cause seizures

Understandable

Information and operation of user interface must be understandable.

Text content is readable and understandable
Pages appear and operate in predictable ways
Users are helped to avoid and correct mistakes
Clear error messages and recovery paths

Robust

Content must be robust enough for interpretation by assistive technologies.

Valid semantic HTML markup
Proper ARIA attributes when needed
Compatible with current and future assistive technologies
Progressive enhancement approach

Rights of Persons with Disabilities Act, 2016

The UX4G Design System 3.0 aligns with India's Rights of Persons with Disabilities Act, 2016, which mandates that all government digital services must be accessible. Compliance is not optional—it is a legal requirement and moral imperative.

Color Guidance

Ensuring sufficient contrast ratios for all text and interactive elements

WCAG Contrast Requirements

Normal Text (WCAG AA)

4.5:1 minimum

For text smaller than 18px or 14px bold

Body text on white background

14.5:1Pass

Primary purple on white

6.2:1Pass

Secondary gray on white

3.2:1Fail

Large Text (WCAG AA)

3:1 minimum

For text 18px+ or 14px+ bold

Large heading on white

5.7:1Pass

Primary on light gray

5.2:1Pass

UI Components (WCAG AA)

3:1 minimum

For interactive elements and graphics

Button border

6.2:1Pass

Input border

3.1:1Pass

Focus ring

3.5:1Pass

Color Blindness Considerations

Deuteranopia

Red-green color blindness (most common)

Original UI

Reject

Approve

Simulated view

Reject

Approve

Protanopia

Red color blindness

Original UI

Alert

Action

Simulated view

Alert

Action

Tritanopia

Blue-yellow color blindness

Original UI

Submit

Warning

Simulated view

Submit

Warning

Design Guidelines

Never rely on color alone to convey information—use text, icons, or patterns
Use high contrast between foreground and background colors
Supplement color with text labels, icons, or patterns for status indicators
Test designs using color blindness simulators during design phase

Testing Contrast

Recommended Tools

• WebAIM Contrast Checker - Online tool for testing color combinations
• Browser DevTools - Built-in accessibility audits in Chrome/Edge
• Figma Plugins - A11y - Color Contrast Checker, Stark
• Automated Testing - axe DevTools, Lighthouse CI

Testing Process

1.Test all text against its background color
2.Verify interactive element contrast (borders, focus states)
3.Check graphic elements and iconography
4.Test in grayscale to ensure information isn't lost

Focus Visibility Rules

Clear, consistent focus indicators for keyboard navigation

Focus Indicator Requirements

Minimum Requirements (WCAG 2.4.7)

Focus indicator must be clearly visible
Minimum 3:1 contrast with adjacent colors
Must be present on all interactive elements
Should not be removed via CSS

UX4G Focus Standard

Ring width:4px

Ring color:rgba(59, 130, 246, 0.5)

Ring offset:2px

Border radius:Matches element

Button Focus

Input Focus

Link Focus

Focused Link

Checkbox Focus

Focused checkbox

Focus Order

Logo/Header

Top-left navigation elements

Main Navigation

Primary navigation menu

Skip Link

Allow skipping to main content

Main Content

Primary page content, left to right, top to bottom

Sidebar

Secondary navigation or filters

Footer Links

Footer navigation and information

Do

• Follow natural reading order (top to bottom, left to right)
• Use semantic HTML for natural tab order
• Test focus order with keyboard only
• Provide skip links for long navigation

Don't

• Don't use positive tabindex values (tabindex="1")
• Don't create confusing focus traps
• Don't hide focus indicators with CSS
• Don't rely on mouse-only interactions

Keyboard Interaction Expectations

Standard keyboard patterns for all interactive components

Standard Keyboard Controls

Tab

Move focus forward to next interactive element

Shift + Tab

Move focus backward to previous interactive element

Enter

Activate buttons, links, and submit forms

Space

Activate buttons, toggle checkboxes, scroll page

Arrow Keys

Navigate within components (menus, tabs, radio groups)

Esc

Close modals, dialogs, dropdowns, and cancel operations

Home

Move to first item in list or beginning of text field

End

Move to last item in list or end of text field

Modal/Dialog

TabCycles focus within modal only (focus trap)
EscCloses modal and returns focus to trigger
EnterActivates primary action button

Dropdown Menu

Space/EnterOpens dropdown menu
Arrow Up/DownNavigates through menu items
EscCloses menu and returns focus
Type aheadJumps to matching menu item

Tabs

TabMoves focus to active tab, then to tab panel
Arrow Left/RightSwitches between tabs
Home/EndJumps to first/last tab

Radio Group

TabMoves focus to selected radio (or first if none selected)
Arrow KeysSelects and moves between radio buttons
SpaceSelects focused radio button

Testing Keyboard Accessibility

Every interactive element must be fully operable via keyboard. Test each page by:

1. Unplug your mouse or disable trackpad
2. Navigate using only Tab, Shift+Tab, Enter, Space, and Arrow keys
3. Verify all functionality is accessible
4. Ensure focus indicators are always visible
5. Check that focus never becomes trapped unintentionally

Semantic Structure Guidance

Using HTML elements correctly for meaning and accessibility

Heading Hierarchy

<h1>Page Title</h1>

One per page

<h2>Section Heading</h2>

Main sections

<h3>Subsection</h3>

Nested under h2

Never skip heading levels

h1 → h3 is incorrect. Always use sequential order.

Landmark Regions

<header>Site/page header with logo and navigation

<nav>Navigation menu or links

<main>Primary content (one per page)

<div>Complementary content or sidebar

<footer>Site/page footer

<section>Thematic grouping of content

<article>Self-contained content

Semantic HTML Patterns

Correct

<button type="submit">Submit</button>

Incorrect

<div onclick="submit()">Submit</div>

Use semantic button element for interactive actions

Correct

<a href="/resources">Navigate</a>

Incorrect

<button onclick="navigate()">Navigate</button>

Use anchor tags for navigation, buttons for actions

Correct

<ul><li>Item 1</li><li>Item 2</li></ul>

Incorrect

<div><div>Item 1</div><div>Item 2</div></div>

Use semantic list elements for lists of items

Form Accessibility

Making forms accessible and easy to complete

Form Accessibility Checklist

Label Association

Every input has an associated label
Labels use htmlFor/id or wrap the input
Labels are always visible (not placeholder-only)
Labels clearly describe the input's purpose

Required Fields

Required fields marked with * or 'Required'
aria-required='true' on required inputs
Clear indication at form start about required fields
Validation triggers on form submit, not during typing

Helper Text

Complex fields have helper text explaining format
Helper text associated with aria-describedby
Character limits announced to screen readers
Examples provided for unclear field types

Input Types

Appropriate input type for content (email, tel, number)
Correct keyboard shown on mobile devices
Date pickers are keyboard accessible
Custom controls have proper ARIA roles

Accessible Form Example

Key Points

htmlFor/id: Label associated with input via matching ids
aria-required: Programmatically indicates required field
aria-describedby: Associates helper text with input
fieldset/legend: Groups related radio buttons semantically
input types: Correct type (email, tel) for better UX
Focus indicators: Clear ring on focus for keyboard users

Error Handling Accessibility

Communicating errors clearly to all users

Error Message Requirements

Clearly identify which field has an error
Explain what went wrong in plain language
Provide guidance on how to fix the error
Show errors inline near the related field
Use aria-invalid='true' on error fields
Associate error message with aria-describedby
Use aria-live for dynamic error announcements
Don't rely on color alone to indicate errors

Example: Error State

Email Address *

Please enter a valid email address (e.g., name@example.com)

Implementation

<input
  aria-invalid="true"
  aria-describedby="error-message"
/>
<div id="error-message" role="alert">
  Error description
</div>

Error Summary Pattern

There are 2 errors in this form

Email Address: Please enter a valid email address
Phone Number: Phone number must be 10 digits

Error Summary Best Practices

Show error summary at top of form after submission
Move focus to error summary or first error field
Provide links to jump to each error field
Use role="alert" or aria-live="assertive" for announcement

Table Accessibility

Making data tables accessible and navigable

Accessible Table Example

Application Status for January 2024
Application ID	Applicant Name	Status	Date
APP-001	Rajesh Kumar	Approved	Jan 15, 2024
APP-002	Priya Sharma	Pending	Jan 18, 2024

Table Requirements

<caption>: Describes table purpose
<thead>, <tbody>: Groups header and body rows
<th scope="col">: Identifies column headers
<th scope="row">: Identifies row headers
Simple structure: Avoid merged cells when possible

Responsive Tables

On mobile viewports, complex tables should transform into a more accessible format:

Convert to card view with labeled data
Allow horizontal scrolling with visible scroll hint
Stack columns vertically for narrow screens
Provide alternative data views (list, grid)

Status Communication

Announcing dynamic changes to assistive technology users

ARIA Live Regions

aria-live="polite"

Announces changes when user is idle. Use for non-critical updates like form validations or status messages.

aria-live="assertive"

Interrupts current announcement. Use sparingly for critical errors or time-sensitive alerts.

role="status"

Equivalent to aria-live="polite". Use for status updates and feedback messages.

role="alert"

Equivalent to aria-live="assertive". Use for critical error messages requiring immediate attention.

Example: Form Submission

Application submitted successfully

<div role="status">Success message</div>

Example: Critical Error

Session expired. Please log in again.

<div role="alert">Error message</div>

Known Limitations Pattern

Transparently documenting accessibility constraints

Transparency in Accessibility

The UX4G Design System 3.0 maintains transparency about any known accessibility limitations. This allows teams to make informed decisions and plan for workarounds or future improvements.

Component	Known Limitation	Workaround	Status
Date Picker	Calendar grid may be difficult to navigate with screen reader	Provide manual text input alternative	In Progress
Rich Text Editor	Complex toolbar navigation requires extensive keyboard patterns	Use native textarea for accessibility-critical forms	Documented
Data Visualization	Complex charts may not convey full information to screen reader users	Provide data table alternative and text description	Resolved

Reporting Accessibility Issues

If you discover an accessibility issue not listed above, please report it to the UX4G team:

Email: support.ux4g@digitalindia.gov.in

Issue Tracker: github.com/dbn1972/DesignSystem2016/issues

Required Information: Component name, assistive technology used, steps to reproduce

← Design Tokens Content Design System →

Accessibility

Important

Accessibility Principles

Perceivable

Operable

Understandable

Robust

Rights of Persons with Disabilities Act, 2016

Color Guidance

WCAG Contrast Requirements

Normal Text (WCAG AA)

Large Text (WCAG AA)

UI Components (WCAG AA)

Color Blindness Considerations

Design Guidelines

Testing Contrast

Recommended Tools

Testing Process

Focus Visibility Rules

Focus Indicator Requirements

Minimum Requirements (WCAG 2.4.7)

UX4G Focus Standard

Focus Order

Do

Don't

Keyboard Interaction Expectations

Standard Keyboard Controls

Modal/Dialog

Dropdown Menu

Tabs

Radio Group

Testing Keyboard Accessibility

Screen Reader Considerations

Essential ARIA Attributes

Visually Hidden Text

Alternative Text

Testing with Screen Readers

NVDA (Windows)

VoiceOver (macOS/iOS)

JAWS (Windows)

TalkBack (Android)

Semantic Structure Guidance

Heading Hierarchy

Landmark Regions

Semantic HTML Patterns

Form Accessibility

Form Accessibility Checklist

Label Association

Required Fields

Helper Text

Input Types

Accessible Form Example

Key Points

Error Handling Accessibility

Error Message Requirements

Example: Error State

Implementation

Error Summary Pattern

There are 2 errors in this form

Error Summary Best Practices

Table Accessibility

Accessible Table Example

Table Requirements

Responsive Tables

Modal & Dialog Accessibility

Modal Accessibility Requirements

Focus Management

Keyboard Support

ARIA Attributes

Screen Reader Support

Status Communication

ARIA Live Regions

Example: Form Submission

Example: Critical Error

Known Limitations Pattern

Transparency in Accessibility

Reporting Accessibility Issues

Accessibility Review Checklist

Pre-Launch Accessibility Checklist

Perceivable