Chapter 38: Accessibility
Accessibility (often shortened to a11y — a11y = accessibility, with 11 letters between a and y)
Accessibility means making your website usable by as many people as possible — including people who:
- are blind or have low vision
- are deaf or hard of hearing
- have motor disabilities (can’t use mouse well, or only use keyboard)
- have cognitive disabilities (dyslexia, ADHD, memory issues)
- are elderly
- are using mobile devices in bright sunlight
- have temporary injuries (broken arm, etc.)
- are using older/slow internet or low-end devices
In short: Accessibility = inclusive design If your site is only usable by young, healthy, sighted, mouse-using people on fast internet → it’s not accessible.
And in 2026 — accessibility is not optional anymore.
- Legal requirements (in many countries including India — RPWD Act 2016 + international WCAG standards)
- SEO boost (Google loves accessible sites)
- Better UX for everyone (good accessibility usually means good design)
- Larger audience (1 in 4–5 people has some form of disability)
Core Principles of Web Accessibility (WCAG 2.2 – 2026 Standard)
WCAG (Web Content Accessibility Guidelines) organizes everything into 4 main principles — remember them as POUR:
| Principle | Meaning | What it really asks you to do |
|---|---|---|
| Perceivable | Can users perceive the content? | Text has enough contrast, images have alt text, videos have captions, nothing relies only on color |
| Operable | Can users operate the interface? | Everything is keyboard accessible, no time limits that can’t be paused, no flashing content that causes seizures |
| Understandable | Can users understand the content & how to use it? | Readable text, predictable navigation, helpful error messages |
| Robust | Can different tools (assistive tech) understand the content? | Valid HTML, proper ARIA when needed, works with screen readers |
Most Important Practical Things You Should Do (2026 Beginner-to-Intermediate Level)
| # | What to do | How to do it (code example) | Why it matters / Who it helps |
|---|---|---|---|
| 1 | Write meaningful alt text on every image | <img src=”chai.jpg” alt=”Cup of Irani chai with Osmania biscuits on table in Hyderabad cafe”> | Screen readers read this. Decorative images get alt=”” (empty) |
| 2 | Use semantic HTML (not just divs) | Use <header>, <nav>, <main>, <article>, <section>, <footer> | Screen readers announce landmarks → blind users jump to main content quickly |
| 3 | Never remove focus outline | Never do *:focus { outline: none; } | Keyboard users (many disabled people) need to see where focus is |
| 4 | Add proper focus styles | :focus { outline: 3px solid #3b82f6; outline-offset: 3px; } | Makes keyboard navigation visible & beautiful |
| 5 | Ensure color contrast ≥ 4.5:1 for normal text | Use tools like WebAIM Contrast Checker | Low-vision users, elderly, bright sunlight |
| 6 | Make forms accessible | Use <label for=”id”>, aria-describedby for errors | Screen reader announces “Email field, required, edit text” |
| 7 | Make everything keyboard accessible | Use Tab key to reach everything, Enter/Space to activate | Motor disabilities, no mouse/trackpad users |
| 8 | Add ARIA labels when needed (but sparingly) | <button aria-label=”Close modal”>×</button> | When visible text is missing or unclear |
| 9 | Use headings in logical order | h1 → h2 → h3 (never skip levels) | Creates proper document outline for screen readers |
| 10 | Test with screen reader (VoiceOver / NVDA / TalkBack) | Free: NVDA (Windows), VoiceOver (Mac), TalkBack (Android) | You’ll be shocked how many “invisible” problems you find |
Real Example – Accessible vs Inaccessible Card Component
Inaccessible version (what many beginners write)
HTML
|
0 1 2 3 4 5 6 7 8 9 10 |
<div class="card" onclick="goToPage()"> <img src="product.jpg"> <h3>Cool Product</h3> <p>₹ 999</p> </div> |
Problems:
- No alt text → blind users hear nothing about the image
- Click handler on div → keyboard users can’t activate it
- No focus style → keyboard users don’t know it’s interactive
- Color contrast might be bad
- No semantic meaning
Accessible version (what you should aim for)
HTML
|
0 1 2 3 4 5 6 7 8 9 10 |
<a href="/product/cool-product" class="card"> <img src="product.jpg" alt="Cool black wireless earbuds with charging case"> <h3>Cool Product</h3> <p class="price">₹ 999</p> </a> |
CSS
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
.card { display: block; text-decoration: none; color: inherit; background: white; border-radius: 12px; box-shadow: 0 4px 12px rgba(0,0,0,0.08); overflow: hidden; transition: transform 0.25s ease, box-shadow 0.25s ease; } .card:focus { outline: 3px solid #3b82f6; outline-offset: 4px; } .card:hover { transform: translateY(-4px); box-shadow: 0 12px 24px rgba(0,0,0,0.12); } .price { font-weight: bold; color: #10b981; } |
Why this is better:
- Uses real <a> → keyboard + screen reader works
- Proper alt text → blind users know what product
- Visible focus style → keyboard users see it
- Semantic + hover/focus feedback → feels modern & inclusive
Quick Accessibility Mastery Checklist (Beginner 2026)
- Every <img> has meaningful alt=”” (or empty for decorative)
- Use semantic HTML (<nav>, <main>, <button>, <a>, not divs for everything)
- Never remove default focus outline — style it beautifully instead
- Check color contrast (aim ≥ 4.5:1 normal text, ≥ 3:1 large text)
- All interactive elements are keyboard reachable (Tab → Enter/Space)
- Forms have <label for=”id”> + id matching
- No auto-playing video/sound without controls
- Test with screen reader once a month (even 10 minutes helps)
How does it feel when you imagine a blind user navigating your site with a screen reader? That moment when you realize “this actually helps real people” is why accessibility becomes addictive.
Next possible lessons — tell me what you want:
- “How to test accessibility (free tools + screen readers)”
- “Common accessibility mistakes beginners make”
- “ARIA roles & attributes — when & how to use”
- “Accessible forms (validation, error messages)”
- “Color contrast & dark mode accessibility”
You’re now entering the responsible developer phase — accessibility is what makes you proud of your work. Chai khatam? Fresh cup lao — let’s make the web better for everyone! 🚀 ♿ 😄
