Accessibility

A Video That "Works Perfectly" — And Still Fails

Meera is in Class 8 in a school in Delhi. She is deaf. Her teacher shares a science video link on the class WhatsApp group — a well-produced explainer on the water cycle, hosted on a fast, reliable server. Meera taps play. The video loads instantly. The picture is sharp. The audio, if she could hear it, plays without a single glitch. By every technical measure, the video "works perfectly." Meera understands almost nothing from it, because there are no captions and no transcript. The information the video was built to deliver never reaches her.

This is the central idea of this chapter, and it is easy to miss if you have never needed to think about it: a piece of software can pass every test a programmer normally runs — it compiles, it loads, it doesn't crash, it looks great on the demo laptop — and still completely fail the person using it. Testing "does the code run" is not the same as testing "can every intended user actually use it." Accessibility is the branch of computer science and design concerned with that second question: building digital products — websites, apps, games, government portals — so that people with a wide range of abilities (visual, auditory, motor, and cognitive) can perceive the content, operate the controls, and understand what is happening, without needing someone else to do it for them.

The Curb-Cut Effect: Why This Is Bigger Than You Think

Walk to the edge of almost any Indian street with a raised pavement and you'll usually find a small ramp cut into the curb near a crossing — a smooth slope replacing the sharp 90-degree step down to the road. These "curb cuts" were originally fought for by wheelchair users in the 1970s, who could not get a wheelchair up or down a sheer stone edge. But watch that same ramp for ten minutes and you'll see it used by far more people than that: a delivery worker pulling a hand-trolley of LPG cylinders, a mother pushing a pram, a cricket-mad kid dragging a bicycle, an elderly grandfather with a walking stick, someone wheeling a suitcase to the metro. A feature built to remove one specific barrier ends up removing friction for almost everyone. Accessibility researchers call this the curb-cut effect, and it is one of the most useful ideas in this entire subject.

The same pattern shows up constantly in software. Captions were fought for by deaf and hard-of-hearing users, but today they are switched on by a hostel student watching a lecture at 1 a.m. without waking a roommate, by someone scrolling Instagram reels on mute during a train commute, and by a student still building English fluency who reads along to confirm what they just heard. Voice assistants were built as an alternative input method for people with limited hand mobility, but they are now used by a driver giving directions hands-free and a cook with turmeric-stained fingers who doesn't want to touch a phone screen. This lets us correct a very common misconception directly: accessibility is not a "feature for a small, separate group of people with disabilities." It is a feature for anyone whose ability to see, hear, or use their hands is reduced — permanently, temporarily, or just for a moment because of the situation they're in. A cricket fan with a fractured wrist in a cast has a temporary motor limitation. Someone reading their phone in harsh Chennai afternoon sun has a situational vision limitation, because low-contrast grey text washes out completely in bright light. Both of them benefit from exactly the same fixes a permanently blind or low-vision user needs.

To see the real scale of this, it helps to know a genuine, widely cited figure: the World Health Organization's World Report on Disability estimates that more than a billion people worldwide — roughly 15% of the global population — live with some form of disability. India's 2011 Census recorded about 2.68 crore people (roughly 2.2% of the population) as having a disability, though disability-rights organisations have long pointed out that census questions tend to undercount the real number, since many forms of disability — including most cognitive and some sensory conditions — are easy to miss with a short survey question. Whatever the exact figure, the underlying point for a software developer is simple: if you build only for the "default" user you imagine in your head, you are guaranteed to be building for a smaller audience than you think.

Four Questions Every Interface Must Answer: POUR

Because "make it accessible" is too vague to actually build against, the organisation that sets the technical standards for the World Wide Web — the W3C (World Wide Web Consortium) — publishes a detailed rulebook called the Web Content Accessibility Guidelines (WCAG). Every single rule in WCAG falls under one of four principles, remembered by the acronym POUR:

• Perceivable — can the user detect that the content exists at all, through at least one of their senses?
• Operable — can the user actually control and navigate the interface, no matter what input device they use?
• Understandable — is the content, and the way the interface behaves, clear and predictable?
• Robust — will it keep working correctly across different assistive technologies, browsers, and devices — including ones that don't exist yet?

The important thing to internalise is that these four are independent failure modes. A page can have gorgeous, high-contrast visuals (Perceivable: fine) and still be completely unusable if every button only responds to a mouse click and none of them can be reached with the Tab key (Operable: broken). Failing even one of the four principles is enough to lock a whole group of users out, no matter how well the other three are handled.

Perceivable: Getting Content Into a Sense the User Actually Has

The most common Perceivable failure on the web is the missing alt text — a short, written description attached to an image, used by screen-reading software when it reaches a picture it cannot show.

<!-- Bad: the image carries no information for a screen-reader user -->
<img src="dhoni-trophy.jpg">

<!-- Good: alt describes exactly what the image communicates -->
<img src="dhoni-trophy.jpg" alt="MS Dhoni lifting the 2011 Cricket World Cup trophy">

When a blind user's screen reader reaches the second version, it announces "Image: MS Dhoni lifting the 2011 Cricket World Cup trophy." On the first version, it announces only "Image, dhoni-trophy.jpg" or sometimes nothing useful at all — the filename is not a description, it's a file path, and it tells a listener nothing about what the photo actually shows.

For video, the equivalent fix is captions — and it's worth being precise about a distinction people often blur. Subtitles assume the viewer can hear the audio fine but doesn't understand the spoken language, so they translate dialogue only. Captions assume the viewer cannot hear the audio at all, so they must also describe meaningful non-speech sound: [applause], [phone ringing], [tense background music]. Meera, from the opening example, needs captions, not just a text version of the narrator's words — she also needs to know if a bell rings to signal an experiment result, or if the video's tone shifts with dramatic music.

Colour and contrast are the other major Perceivable concern, and this is where we can bring in some real, checkable arithmetic. WCAG defines a numeric contrast ratio between text and its background, calculated from each colour's relative luminance — a brightness score between 0 (pure black) and 1 (pure white) that a colour-contrast tool computes for you. Once you have the luminance values, the ratio itself is simple arithmetic:

Contrast Ratio = (L1 + 0.05) / (L2 + 0.05)

where L1 = luminance of the LIGHTER colour
      L2 = luminance of the DARKER colour

Let's work through three real examples, using luminance values a contrast-checker tool would report:

1. Pure black text (L = 0) on pure white background (L = 1): Ratio = (1 + 0.05) / (0 + 0.05) = 1.05 / 0.05 = 21:1. This is the maximum possible contrast ratio in the whole system — you cannot do better than black-on-white or white-on-black.
2. Medium-grey text, hex colour #767676 (L ≈ 0.181), on white (L = 1): Ratio = 1.05 / (0.181 + 0.05) = 1.05 / 0.231 ≈ 4.54:1. This colour is famous among accessibility engineers as roughly the darkest grey you can go before failing WCAG's minimum requirement for normal-sized text.
3. Lighter grey text, hex colour #AAAAAA (L ≈ 0.402), on white (L = 1): Ratio = 1.05 / (0.402 + 0.05) = 1.05 / 0.452 ≈ 2.32:1. This looks perfectly readable to someone with good vision sitting close to a bright screen indoors — and it fails badly for anyone with low vision, or anyone using a phone outdoors in daylight glare.

WCAG's actual pass/fail thresholds are: 4.5:1 minimum for normal body text, a relaxed 3:1 for large text (18pt+ or bold 14pt+) and for meaningful UI graphics like icons, and a stricter 7:1 for the "Enhanced" level some government and banking sites aim for. Compare our three examples against those numbers: example 1 passes everything with huge margin, example 2 just barely passes the normal-text minimum, and example 3 fails outright. Note that computing the exact luminance value from a raw RGB colour involves a gamma-correction step with exponents you'll meet properly in later grades — for now, treat the luminance number as something a tool hands you, and focus on the ratio arithmetic and the thresholds, because that's the part an interface designer actually reasons with every day.

One more Perceivable rule worth knowing because it can be a genuine safety issue: WCAG forbids content that flashes more than three times per second, because rapid flashing can trigger seizures in users with photosensitive epilepsy. This is why professionally made games and video ads avoid strobing effects, or add an explicit warning before them.

Operable: Can You Control It Without a Mouse?

Many users cannot use a mouse or a touchscreen at all — because of a motor disability, a temporary injury, or simply because they navigate primarily with a physical keyboard. On any accessible page, pressing the Tab key should move a visible focus indicator through every interactive element in a sensible order, and pressing Enter or Space should activate whatever is currently focused. This sounds automatic, but it depends entirely on which HTML tag you chose to build a control from:

<!-- Bad: looks exactly like a button, but the Tab key skips right past it -->
<div onclick="submitForm()">Submit</div>

<!-- Good: a real <button> is automatically keyboard-focusable and activatable -->
<button onclick="submitForm()">Submit</button>

Trace through why the first one actually breaks: the browser's Tab key only moves focus between elements that are on its built-in "focusable" list — links, form fields, and a handful of other native controls, <button> included. A plain <div> is not on that list by default, no matter how you style it to look like a button with CSS. A keyboard-only user tabbing through the page will jump straight from the field before it to the field after it, never landing on that div at all — the "Submit" control simply does not exist for them, even though it renders perfectly on screen. The fix in the second line costs nothing extra: swap the tag, keep the same onclick, and the browser gives you keyboard support for free.

Operable also covers timing: if a page auto-logs a user out after 60 seconds of inactivity (common on banking and UPI-linked sites), WCAG requires either a warning with a chance to extend the time, or no hard timeout at all — because a screen-reader user reading a long confirmation screen line by line, or someone with a motor disability who types slowly, may need far longer than 60 seconds to complete a routine action through no fault of their own.

Understandable: Predictable Content, Predictable Behaviour

An interface can be perfectly perceivable and operable and still confuse users if its language or behaviour is unpredictable. Compare two error messages for the same failed form field:

<!-- Bad: technically true, communicates nothing actionable -->
<p>Error: Invalid input (code 400)</p>

<!-- Good: says exactly what is wrong and how to fix it -->
<p>Enter a valid 10-digit mobile number, e.g. 9876543210</p>

The first version fails a sighted user too — but it is disproportionately worse for a screen-reader user, who cannot glance at the surrounding form to guess what "code 400" might mean, and for a user with a cognitive or learning disability, who needs the instruction spelled out rather than inferred. Understandable design also means interfaces should behave the way users expect: a page shouldn't silently submit a form or jump the user to a new screen just because focus moved into a dropdown, because that kind of surprise is disorienting for a screen-reader user who navigates linearly and has no peripheral vision of the whole screen to notice the jump.

Robust: How a Screen Reader Actually Reads a Page

The Robust principle is where "div soup" — building a whole page out of generic, meaningless <div> tags with no semantic structure — does the most damage, because it breaks the exact mechanism assistive technology depends on. Tools like TalkBack (Android), VoiceOver (iPhone), and NVDA or JAWS (Windows) do not "see" a page visually at all. They walk through the page's underlying structure — the DOM (Document Object Model), the tree of tags you write in your HTML — strictly in source order, and for each element they announce its role (heading, link, button, image, navigation region) using the tag or ARIA attribute you gave it, plus its name (its visible text, or its alt/aria-label if it has no visible text). If your page is a flat pile of unlabeled <div>s, every single one of these announcements collapses into the same useless word: "group... group... group."

This is also why generic-looking icon buttons need an explicit name:

<!-- Bad: screen reader announces just "button" — a button to do what? -->
<button onclick="playAudio()">▶</button>

<!-- Good: aria-label supplies the missing name -->
<button onclick="playAudio()" aria-label="Play pronunciation audio">▶</button>

The diagram below shows this mechanism end to end: a small cricket-scores page as a sighted user sees it, and the exact linear sequence a screen reader speaks out loud when it walks that page's DOM in order.

Notice that the screen reader has no way to describe the sun, the mountain icon, or the layout at all — it can only speak the role the tag declares and the name that text or attributes give it. If the developer had used four unlabeled <div>s instead of <h1>, <nav>, <img alt="...">, and <button>, every one of those four announcements in the right-hand column would have collapsed into a flat, meaningless "group, group, group, group" — the visual page would look identical, but it would have become functionally invisible to a blind user. This lets us correct a second common misconception directly: accessibility is not "just making the font bigger." Font size only helps with one narrow slice of one principle (Perceivable, for some low-vision users). It does nothing at all for a blind user relying on structure and alt text, a deaf user relying on captions, or a motor-disabled user relying on keyboard support — which is exactly why WCAG needs four separate principles rather than one.

Accessibility Law and Practice in India

Accessibility in India isn't only a design best-practice — it is backed by law. The Rights of Persons with Disabilities Act, 2016 (RPWD Act) replaced an older 1995 law and explicitly recognises 21 categories of disability, placing a legal duty on government and certain private establishments to provide accessible information and communication technology, including websites. Alongside this, the Accessible India Campaign (Sugamya Bharat Abhiyan), launched in 2015 by India's Department of Empowerment of Persons with Disabilities, set out to improve accessibility across the built environment, transportation, and digital services. On the technical side, the Guidelines for Indian Government Websites (GIGW), maintained under the National Informatics Centre, require official government websites to meet WCAG-level accessibility standards — the same POUR-based rules covered in this chapter, applied at national scale, to portals like IRCTC ticket booking, UIDAI's Aadhaar services, and state government e-governance sites that hundreds of millions of citizens rely on. A blind citizen using TalkBack to book a train ticket, or a citizen with a motor disability navigating a government form entirely by keyboard, depends on exactly the semantic HTML, alt text, and contrast choices this chapter has walked through — not as an abstract ideal, but as a functioning legal requirement.

Check Your Understanding

• Calculate: A button's text has luminance L = 0.15; its background has luminance L = 0.9. Using Contrast Ratio = (L1 + 0.05) / (L2 + 0.05), compute the ratio. Does it pass the 4.5:1 minimum for normal text? (Work it out before checking: (0.9+0.05)/(0.15+0.05) = 0.95/0.20 = 4.75 — it passes, but only just.)
• Match the barrier to the fix: alt text, captions, keyboard navigation, colour contrast. Which one specifically helps a deaf user? Which one specifically helps someone who cannot use a mouse? Which two overlap for a low-vision user?
• Debug this code: <div onclick="deleteItem()">Delete</div>. Name the exact Operable failure and rewrite it correctly.
• Apply the curb-cut effect: Name one accessibility feature (other than captions or ramps) and describe a specific non-disabled person or situation where it also helps.
• Explain the misconception: In your own words, why is "accessibility just means bigger fonts" wrong? Name one disability type that bigger fonts do nothing for.

Summary

• Accessibility means designing so people with different visual, auditory, motor, and cognitive abilities can perceive, operate, and understand a product — "it runs without errors" is not the same as "everyone can use it."
• The curb-cut effect shows accessibility features built for one group (deaf users, wheelchair users) end up helping far more people, including anyone with a temporary or situational limitation.
• WCAG organises every accessibility rule under four principles — POUR: Perceivable, Operable, Understandable, Robust — and failing any single one excludes users regardless of how well the others are done.
• Contrast ratio is calculated as (L1 + 0.05) / (L2 + 0.05); black-on-white gives the maximum 21:1, while thresholds of 4.5:1 (normal text), 3:1 (large text/icons), and 7:1 (enhanced) decide pass or fail.
• A real <button> is keyboard-focusable by default; a styled <div> is not — this is why semantic HTML tags matter more than how something merely looks.
• Screen readers (TalkBack, VoiceOver, NVDA, JAWS) walk the page's DOM in source order and announce each element's role and name — which is why unlabeled "div soup" and missing alt text make a page functionally invisible even when it looks fine.
• In India, the RPWD Act 2016, the Sugamya Bharat Abhiyan, and the GIGW guidelines make WCAG-based accessibility a legal requirement for government digital services, not just a design preference.