Accessibility-First Web Development: ARIA, Screen Readers, and Inclusive Coding

Accessibility-first web development means designing and coding websites that work for everyone, including the 2.68 crore Indians with disabilities who use assistive technologies like screen readers, voice controls, and switch devices. Following WCAG 2.2 AA standards, using semantic HTML, and implementing ARIA (Accessible Rich Internet Applications) attributes correctly ensures your website is usable by all visitors. Under India’s Rights of Persons with Disabilities Act 2016 and upcoming GIGW 3.0 guidelines, government and public-sector websites are legally required to meet accessibility standards, and private companies face growing regulatory and commercial pressure.

Last updated October 2026

Why Accessibility Matters for Indian Websites

Accessibility is not just compliance — it’s business sense and ethical responsibility:

• Market size: 2.68 crore people with disabilities (Census 2011, likely significantly undercounted) plus millions of elderly users with age-related impairments
• Legal requirements: RPwD Act 2016 mandates accessibility for government services. GIGW (Guidelines for Indian Government Websites) requires WCAG 2.0 AA compliance. The Supreme Court has upheld digital accessibility as a right
• SEO benefits: Accessible websites perform better in search because accessibility best practices (semantic HTML, alt text, proper heading structure, fast loading) align with SEO best practices
• Mobile users: Accessibility improvements benefit all mobile users — larger tap targets, readable text, clear navigation. India’s 80%+ mobile internet population benefits directly
• Temporary disabilities: A broken arm, an eye infection, using your phone in bright sunlight — everyone experiences temporary accessibility needs

Understanding WCAG 2.2 Standards

WCAG (Web Content Accessibility Guidelines) 2.2, published by the W3C, is organised around four principles:

Perceivable

Content must be presentable in ways all users can perceive:

• Text alternatives: Every image needs meaningful alt text. Not “image1.jpg” but “Team brainstorming session at The MAD’s Udaipur office”
• Captions and transcripts: Video content needs captions (critical for Hindi and English content in India). Audio content needs transcripts
• Colour contrast: Minimum 4.5:1 ratio for normal text, 3:1 for large text. Test with tools like WebAIM Contrast Checker
• Don’t rely on colour alone: Error messages should use text/icons alongside red colour. Charts should use patterns alongside colours

Operable

All functionality must be operable through various input methods:

• Keyboard navigation: Every interactive element must be reachable and operable via keyboard alone (Tab, Enter, Space, Arrow keys, Escape)
• Focus visibility: Users must be able to see which element has keyboard focus. Never remove focus outlines without providing a visible alternative
• Skip navigation: A “Skip to main content” link as the first focusable element, allowing keyboard users to bypass repeated navigation
• Touch targets: Minimum 44×44 pixels for touchscreen targets — critical for Indian mobile users, many using budget smartphones with imprecise touch
• Motion and animation: Respect prefers-reduced-motion media query. Don’t autoplay videos with audio

Understandable

Content and interface must be understandable:

• Language declaration: <html lang="en"> or <html lang="hi"> — tells screen readers which language pronunciation to use
• Consistent navigation: Navigation menus should appear in the same location and order across all pages
• Error identification: Form errors must clearly identify which field has an error and describe how to fix it
• Predictable behaviour: Elements should behave as expected. A checkbox shouldn’t navigate to a new page

Robust

Content must be interpretable by a wide variety of assistive technologies:

• Valid HTML: Properly nested elements, closed tags, unique IDs
• ARIA when needed: Use ARIA attributes to enhance (not replace) semantic HTML
• Status messages: Dynamically updated content (form submissions, notifications) must be announced to screen readers

ARIA: When and How to Use It

ARIA (Accessible Rich Internet Applications) adds accessibility information to HTML elements. The first rule of ARIA: don’t use ARIA if native HTML can do the job.

Common ARIA Patterns

• aria-label: Provides an accessible name when visible text isn’t sufficient. <button aria-label="Close navigation menu">✕</button>
• aria-describedby: Links an element to its description. Useful for form fields with help text
• aria-expanded: Indicates whether a collapsible element (accordion, dropdown) is open or closed
• aria-live: Announces dynamic content changes to screen readers. “polite” for non-urgent updates, “assertive” for critical alerts
• role: Defines the purpose of an element. role="navigation", role="alert", role="dialog"
• aria-hidden=”true”: Hides decorative elements from screen readers (decorative icons, background images)

Common ARIA Mistakes

1. Using ARIA instead of semantic HTML: <div role="button"> when <button> works. Native HTML elements have built-in keyboard handling and screen reader support
2. Redundant ARIA: <nav role="navigation"> — the <nav> element already has an implicit navigation role
3. aria-label on non-interactive elements: Screen readers may not announce aria-label on <div> or <span> elements unless they have an interactive role
4. Missing ARIA updates: Adding aria-expanded=”false” to a toggle button but never updating it to “true” when expanded

Screen Reader Testing for Indian Developers

Test with actual screen readers, not just automated tools:

For Indian web developers, the minimum testing combination is: NVDA on Chrome/Windows (desktop) and TalkBack on Chrome/Android (mobile). These cover the vast majority of Indian assistive technology users.

Practical Accessibility Checklist for Indian Developers

1. Semantic HTML: Use <header>, <nav>, <main>, <footer>, <article>, <aside>. Stop using <div> for everything
2. Heading hierarchy: One <h1> per page, then <h2>, <h3> in order. Never skip levels for styling (use CSS for that)
3. Alt text: Descriptive for informational images, empty (alt="") for decorative images. Alt text for complex images (charts, infographics) should describe the key information
4. Form labels: Every form input needs a <label> with a matching for attribute. Placeholder text is NOT a substitute for labels
5. Focus management: Visible focus indicators on all interactive elements. Logical tab order. Focus trapping inside modals
6. Colour contrast: 4.5:1 minimum for body text, 3:1 for large text and UI components
7. Responsive and zoomable: Content must be usable at 200% browser zoom without horizontal scrolling
8. Video captions: Provide captions for all video content, in both Hindi and English where applicable
9. Error handling: Clear, specific error messages positioned near the relevant form field
10. Testing: Automated (axe DevTools, WAVE) + manual keyboard testing + screen reader testing

Accessibility for WordPress and Elementor

For WordPress developers building with Elementor (like The MAD’s stack):

• Choose accessible themes: Hello Elementor is lightweight and avoids accessibility anti-patterns common in complex themes
• Elementor accessibility features: Enable “Improve Accessibility” in Elementor settings. Use the built-in heading widgets (not styled paragraphs) for proper heading hierarchy
• Image alt text: Set alt text in the WordPress Media Library, not just in Elementor widgets. This ensures alt text persists if you change builders
• Contact forms: Elementor Pro’s form widget generates proper labels. Test form error handling with a screen reader
• Animation accessibility: Elementor’s entrance animations should not hide content permanently. Content must be accessible even if animations fail to play

Frequently Asked Questions

Is web accessibility legally required for private companies in India?

The RPwD Act 2016 primarily mandates accessibility for government and government-funded entities. However, private companies providing public services face increasing legal risk. Several Indian courts have ruled that digital services are covered under accessibility mandates. Additionally, companies serving EU or US customers must comply with their respective accessibility laws (EAA, ADA). The trend is clearly toward mandatory private-sector accessibility.

How much does it cost to make an existing Indian website accessible?

For a typical 20–50 page WordPress site: ₹50,000–₹2 lakh for an accessibility audit and remediation. For a large e-commerce site: ₹2–10 lakh depending on the severity of issues. Ongoing maintenance: ₹10,000–₹30,000/month for testing new content and features. Building accessibility from scratch is 5–10% of development cost; retrofitting is 2–5x more expensive.

Do accessibility overlays (like accessiBe or UserWay) actually work?

No. Accessibility overlay widgets that promise one-click compliance are widely criticised by the accessibility community. They don’t fix underlying code issues, can interfere with actual assistive technology, and provide a false sense of compliance. Invest in fixing your code properly rather than adding an overlay widget. The ₹30,000–₹50,000/year spent on overlay subscriptions is better spent on actual accessibility improvements.

How do I handle accessibility for Hindi and multilingual content?

Declare the language of each page and language changes within content using the lang attribute. Screen readers use this to switch pronunciation. For Hindi content: <html lang="hi">. For mixed content: wrap Hindi sections in <span lang="hi">. Ensure Hindi fonts are readable at accessible sizes (16px minimum, ideally 18px+ for Devanagari script which is denser than Latin).

What automated accessibility testing tools should Indian developers use?

Start with free tools: axe DevTools browser extension (most comprehensive), WAVE by WebAIM (visual feedback), Lighthouse accessibility audit (built into Chrome). For CI/CD integration: axe-core or Pa11y in your test pipeline. Remember that automated tools catch only 30–40% of accessibility issues — manual testing with keyboard navigation and screen readers is essential for the remaining 60–70%.