Web Accessibility: Building for All 1.4 Billion

Who Gets Left Out, and Why It Is Not a Small Number

Open IRCTC, a school fee-payment portal, or any app on your phone right now — for you, it just works. You see the page, tap the right button, and move on without thinking about it. But according to Census 2011, India's last full national count of disability, about 2.68 crore people (2.21% of the population at the time) live with a disability that affects how they see, hear, move, or process information. Some cannot see a screen at all and rely on software called a screen reader, which speaks the page aloud. Some cannot use a mouse or a touchscreen and operate a computer only through a keyboard or a single switch. Some cannot hear a video's audio track. And far beyond that fixed number, almost everyone experiences a temporary or situational version of the same limits at some point: a parent booking a train ticket one-handed while holding a baby, a delivery rider glancing at a map app in harsh midday glare, a commuter on a crowded Mumbai local who cannot turn the sound on. If a website is written assuming every visitor sees, clicks, and hears exactly the way its developer did while testing it, all of these people are silently locked out — not because they lack ability, but because the code lacks accommodation. Web accessibility is the engineering discipline of writing HTML, CSS, and JavaScript so that the same page keeps working correctly no matter how a person perceives it or operates it. This chapter teaches the actual mechanics of how that is done in real code — not slogans about "inclusion," but specific, testable rules you can apply to any page you build.

What "Accessibility" Actually Means

A common misconception is that accessibility is only about blind users and screen readers. That is one important case, but it is only one of several categories a working developer has to design for:

• Visual — blindness, low vision, and colour blindness (roughly 1 in 12 men worldwide has some form of red-green colour blindness).
• Auditory — deafness or reduced hearing, which affects anything that depends on sound: videos, audio alerts, voice notes.
• Motor — limited or no fine control of hands, which affects anything that assumes a precise mouse click or a fast tap-and-drag gesture.
• Cognitive — conditions such as dyslexia or attention differences, affected by cluttered layouts, unclear instructions, or aggressive time limits.

A fifth category is easy to underestimate but matters just as much in production code: situational and temporary limits — a fractured wrist in a cast, a cracked phone screen, a slow railway-platform Wi-Fi connection that will not load images, bright outdoor sunlight washing out low-contrast text. Design correctly for the permanent cases above, and you fix nearly all of the situational ones for free. That is the real reason accessibility is treated as a correctness property of code — like handling an empty text field or a dropped network request — rather than a bonus feature added on for a small group of users.

How a Screen Reader Actually Reads a Page

To understand why specific HTML choices matter, you need an accurate mental model of what a screen reader does. It does not take a screenshot and run image recognition on it. It reads the DOM — the Document Object Model, the tree of elements the browser builds from your HTML — and converts it into a second, simplified tree called the accessibility tree. Every element that reaches this tree carries three pieces of information: a role (what kind of control this is — button, heading, link, checkbox), a name (what it should be called out loud), and a state (is it checked, expanded, disabled, currently selected). The screen reader then speaks that tree aloud, one node at a time, in the order elements appear in the HTML source — not the order they appear visually on the screen.

This single fact explains why the choice of HTML tag is not cosmetic. Compare these two elements, which can be made to look pixel-identical with CSS:

<!-- Version A: a div pretending to be a button -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Version B: an actual button element -->
<button onclick="submitForm()">Submit</button>

Version A gets no meaningful role in the accessibility tree, is not reachable by pressing Tab, and does not respond to the Enter or Space key at all — a keyboard user simply cannot activate it. Version B automatically receives role="button", becomes part of the Tab order, responds to both Enter and Space by default, and a screen reader announces "Submit, button" the moment it receives focus. Nobody wrote extra code to get any of that in Version B — the browser provides it for free, because <button> is a native interactive element. This is the core argument for semantic HTML: choosing the tag that matches what the element actually is gives you correct accessibility behaviour automatically, while a generic <div> gives you none of it and forces you to rebuild all of that behaviour yourself in JavaScript, imperfectly.

Why HTML Order Is Not the Same as Visual Order

Modern CSS — Flexbox's order property, CSS Grid placement, position: absolute — lets a developer rearrange elements visually without touching the HTML at all. This is convenient for layout and dangerous for accessibility, because Tab order and screen-reader reading order always follow the HTML source, never the visual position on screen. The diagram below shows a sign-up form where CSS has visually moved the Password field to the front of the row for design reasons. A sighted mouse user never notices, because they simply click whichever box they need. A keyboard or screen-reader user experiences something confusing: pressing Tab from the page heading lands them on "Full Name," not on the field that visually appears first.

This is formally WCAG Success Criterion 1.3.2, "Meaningful Sequence": the reading order encoded in the markup must make sense entirely on its own, independent of whatever CSS is layered on top of it. The fix is simple once the rule is understood: write your HTML elements in the order a person should experience them, and use CSS only to change how things look — never to silently rewrite the order that keyboard and screen-reader users will follow.

The Four Pillars: POUR

Professional accessibility work is organised around four testable principles defined by the Web Content Accessibility Guidelines (WCAG), maintained by the World Wide Web Consortium (W3C). Every rule you will apply in practice falls under one of these four:

1. Perceivable — information must reach every sense; nothing may depend on sight alone, colour alone, or sound alone.
2. Operable — every interactive control must be usable without a mouse and without an unreasonable time limit.
3. Understandable — text and interface behaviour must be predictable, and errors must be explained, not just flagged.
4. Robust — markup must be well-formed enough that current and future assistive technologies can parse it reliably.

The rest of this chapter works through Perceivable and Operable in the depth needed to actually apply them in code, since those are where Grade 9 web development work connects most directly.

Perceivable: Text Alternatives for Images

Every image on a page needs a decision, not a default. If the image conveys information — a chart, a diagram, a photo that is part of the content — it needs an alt attribute that states what the image communicates, written the way you would describe it over the phone to someone who cannot see it. If the image is purely decorative — a border flourish, a background texture — it should carry alt="", an explicitly empty attribute, which tells the screen reader to skip it entirely and move on.

<!-- Informative image: alt states what it conveys, not just what it shows -->
<img src="rainfall-chart.png" alt="Bar chart: Mumbai monthly rainfall, peaking near 800mm in July">

<!-- Decorative image: empty alt tells the screen reader to skip it -->
<img src="border-swirl.png" alt="">

<!-- Wrong, and worse than having no alt at all -->
<img src="rainfall-chart.png" alt="rainfall-chart.png">

The third example is a mistake nearly every beginner makes at least once, and it is worth understanding exactly why it is actively harmful rather than merely lazy. A screen reader will read that alt text aloud literally: "rainfall dash chart dot png, image." That tells the listener nothing about rainfall in Mumbai — it wastes their time and gives them zero usable information, which is worse than an honest gap. An empty alt="" is not a lazy shortcut; it is the technically correct choice for decoration, and it is different from omitting the attribute altogether, which causes some screen readers to fall back to reading out the full image file path.

The same "not by sight alone" principle applies beyond images. A common design mistake is marking a required form field only by colouring its border red, or showing a validation error only as a red asterisk with no accompanying text. A colour-blind user, or anyone using a black-and-white printout or a very low-contrast screen, gets no signal at all. The fix costs nothing: pair the colour with a text label or an icon that carries the same meaning independently — for example, a red border plus the words "Required" or "Invalid PIN code," not the red border alone.

Perceivable: Colour Contrast — the Actual Formula

WCAG does not say "make sure text is readable" and leave the judgment to opinion — it defines an exact, computable number called the contrast ratio and sets a minimum for it. Every colour has a relative luminance, a value between 0 (behaves like pure black) and 1 (behaves like pure white), calculated from its red, green, and blue channels through a gamma-correction step that is more advanced arithmetic than we need here — for this chapter, what matters is what you do with the luminance numbers once you have them, whether computed by hand or read off a contrast-checking tool. For two colours with luminance L1 (the lighter one) and L2 (the darker one), the contrast ratio is:

contrast ratio = (L1 + 0.05) / (L2 + 0.05)

The "+0.05" added on both sides accounts for a small amount of light that scatters even off a screen showing "pure black," and it stops the formula from dividing by a number too close to zero.

Worked example 1 — the two extremes. Pure white background has luminance L1 = 1.0; pure black text has luminance L2 = 0.0:

contrast ratio = (1.0 + 0.05) / (0.0 + 0.05) = 1.05 / 0.05 = 21

21:1 is the maximum possible value this formula can produce — black text on a white background (or the reverse) is the highest-contrast combination that exists, which is exactly why it is the default for dense reading text.

Worked example 2 — a "subtle" grey, the mistake students actually make. Suppose a designer sets body text to a soft grey with luminance L2 = 0.2, kept on the same white background, L1 = 1.0:

contrast ratio = (1.0 + 0.05) / (0.2 + 0.05) = 1.05 / 0.25 = 4.2

WCAG Level AA requires a contrast ratio of at least 4.5:1 for normal body text, and at least 3:1 for large text (roughly 24px, or 19px bold, and above). A ratio of 4.2 fails the 4.5:1 requirement — it can look perfectly fine to someone with typical vision on a bright new laptop screen indoors, and be genuinely hard to read for someone with low vision, or for anyone checking their phone outdoors in strong sunlight. This is precisely why "it looks okay to me" is not a valid accessibility test: contrast is a number you compute or measure with a tool, not a feeling you check by glancing at your own screen once.

Operable: Keyboard Navigation Without a Mouse

WCAG requires that all page functionality be operable using a keyboard alone (Success Criterion 2.1.1, "Keyboard"), and that a keyboard user is never trapped inside a component with no way to Tab back out (Success Criterion 2.1.2, "No Keyboard Trap"). To verify this on any page you build, unplug the mouse, or simply stop using it, and try to reach and activate every link, button, and form field using only Tab, Shift+Tab, Enter, and Space.

Two concrete practices break this constantly in real code. The first is a broad CSS rule that removes the visible focus outline for the sake of a "cleaner" design:

/* Bad: removes ALL keyboard focus indication, site-wide */
*:focus { outline: none; }

/* Good: keep a strong, visible outline specifically for keyboard focus */
button:focus-visible, a:focus-visible, input:focus-visible {
  outline: 3px solid #2b6cb0;
  outline-offset: 2px;
}

Deleting every focus outline does not make the page more elegant for a keyboard user — it makes it unusable, because they lose the only visual signal telling them where on the page they currently are. The fix above uses the modern :focus-visible pseudo-class, which browsers apply mainly when focus arrived via keyboard rather than a mouse click, so a mouse user does not see an outline flash on every click while a keyboard user always sees exactly where they are.

The second common mistake is misusing the tabindex attribute to try to control the order elements are visited in. tabindex="0" correctly adds a custom, non-native element into the natural tab order at its position in the HTML — useful for a widget you have built yourself. tabindex="-1" removes an element from the Tab sequence while still allowing it to be focused programmatically (for example, moving focus to an error message after a failed form submission). A positive value, such as tabindex="5", is a well-known anti-pattern: it overrides the natural order with a manually numbered sequence that is nearly impossible to keep consistent as a page grows, and it frequently produces a confusing Tab order that jumps around unpredictably. The correct way to change Tab order is never a positive tabindex — it is reordering the actual elements in the HTML source, the same fix already established in the diagram above.

Understandable and Robust: Labels and the First Rule of ARIA

Form fields need a name a screen reader can announce, and a attribute does not reliably provide one. A is visual hint text that vanishes the moment a user starts typing, and many screen readers do not treat it as the field's actual accessible name at all.

<!-- Wrong:  disappears on typing, and often isn't announced as a name -->
<input type="email" ="Email address">

<!-- Right: label is programmatically tied to the input via id / for -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

With the correct version, the moment the input receives focus, a screen reader announces "Email address, edit text" — the person knows exactly what is expected before they type a single character. With the -only version, many screen reader and browser combinations announce nothing but "edit text," giving no clue what to type at all.

This leads to a rule worth memorising exactly as it is usually taught to professional developers: the first rule of ARIA is not to use ARIA if a native HTML element already does the job. ARIA (Accessible Rich Internet Applications) is a set of attributes — role, aria-label, aria-expanded, and others — that can describe custom widgets to the accessibility tree. But ARIA only ever changes what gets announced; it never adds any actual browser behaviour.

<!-- Unnecessary and error-prone: reinventing a button using ARIA -->
<div role="button" tabindex="0" onclick="save()" onkeydown="handleKey(event)">Save</div>

<!-- Correct: the native element already provides role, keyboard handling, and focus -->
<button onclick="save()">Save</button>

In the first version, role="button" makes a screen reader announce "Save, button," but pressing Enter or Space still does nothing unless the developer's own handleKey(event) function correctly detects those exact keys and calls save() itself — a detail that is very easy to get wrong or forget. In the second version, <button> gives all of that behaviour automatically, in every browser, with no extra JavaScript. This directly corrects a common misconception: adding ARIA attributes to an element does not, by itself, make that element accessible. ARIA supplements native semantics for cases where no native element fits (a custom dropdown menu, a tab panel); it is never a substitute for choosing the right native tag in the first place.

Testing Your Own Page Like a Real User

Four checks catch the large majority of accessibility bugs before a page ever ships:

• The keyboard-only test — stop using the mouse or trackpad entirely, and Tab through the whole page. Every interactive element should be reachable, and it should be visually obvious at every moment which one currently has focus.
• The image sweep — check that every informative <img> has a meaningful alt, and every purely decorative one has alt="".
• A contrast check — measure body text against its background and confirm it meets 4.5:1 (or 3:1 for large text) rather than eyeballing it.
• A real screen reader pass — every Android phone already has TalkBack built in (Settings → Accessibility → TalkBack), and every iPhone has VoiceOver (Settings → Accessibility → VoiceOver); turning either on for five minutes on your own page reveals problems no amount of visual inspection will show, because you are forced to experience the page exactly the way it gets announced rather than the way it looks.

Where This Fits in Your CBSE Work

This topic connects directly to two parts of the Computer Science / Informatics Practices syllabus: the practical unit on HTML and web development, where semantic tags, forms, and labels are already core content, and the unit on the societal impact of information technology, which expects you to reason about inclusion and responsible design choices, not just correct output. WCAG is also a useful concrete example of something you will meet again and again in technical work: a formal, versioned specification (maintained by the W3C) that translates a general goal — "make the web usable by everyone" — into exact, testable numeric rules like the 4.5:1 contrast ratio. Learning to read and apply a specification precisely, rather than working from a vague impression of what it probably says, is itself a skill that both board exams and real engineering work reward.

Check Your Understanding

1. A developer writes <div onclick="playVideo()">▶</div> for a play button. Name two concrete problems a keyboard-only user will hit, and rewrite the line so both are fixed.
2. Two colours give a contrast ratio of 3.8:1 for normal 16px body text. Does this pass WCAG Level AA? State the exact number you are comparing it against and why it fails or passes.
3. True or False, with a one-sentence reason: "Adding role="button" to a <span> makes it fully keyboard-accessible on its own."
4. A student sets alt="photo123.jpg" on a meaningful photograph. Explain concretely what a screen reader user hears, and what the alt text should say instead.
5. In one sentence, explain why changing a field's visual position with CSS order does not change its Tab order.

Self-check answers: (1) It cannot receive keyboard focus at all, and even if it somehow could, Enter/Space would not trigger playVideo() without extra hand-written key-handling code; the fix is <button onclick="playVideo()">▶</button>. (2) No — WCAG AA requires at least 4.5:1 for normal text, and 3.8 is below that threshold. (3) False — ARIA's role only changes what gets announced; it adds no keyboard behaviour, so Enter/Space would still need to be wired up manually, and the element still would not be in the Tab order without also adding tabindex="0". (4) The screen reader reads the filename aloud literally ("photo one two three dot jpg"), which conveys nothing about the photo's content; the alt should describe what the photograph actually shows. (5) Tab order and screen-reader order are both determined by the position of elements in the HTML source (the DOM), and CSS properties like order only change how elements are painted on screen, never where they sit in that underlying source.

Summary

Web accessibility is not a checklist bolted onto a finished page — it is a set of testable engineering constraints, organised under WCAG's four pillars of Perceivable, Operable, Understandable, and Robust. A screen reader reads the DOM's accessibility tree in HTML source order, not the order things appear visually, which is why CSS-driven reordering can silently break navigation for keyboard and screen-reader users even when the page looks perfect. Semantic tags such as <button> and <label> provide correct roles, names, states, and keyboard behaviour automatically; a <div> or ARIA attribute alone provides none of that behaviour and forces the developer to rebuild it by hand, imperfectly. Colour contrast is governed by an exact formula, (L1 + 0.05) / (L2 + 0.05), with a real numeric minimum of 4.5:1 for normal text — not a subjective impression of readability. None of this is a side concern for a country of roughly 1.4 billion people, spanning every possible combination of ability, device, network speed, and lighting condition: writing correct, semantic, keyboard-operable, sufficiently contrasted HTML is simply what it means to build a website that actually works for the people who will use it.

Think About It

Think about this: How would you explain web accessibility: building for all 1.4 billion to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.