Web Accessibility (A11y)
Build web applications that work for everyone: master POUR principles, native semantic HTML, keyboard navigation with visible focus, accessible forms, descriptive alt text, color contrast, and pragmatic ARIA.
The Universal Web Promise
Tim Berners-Lee famously stated: “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
Web accessibility (often abbreviated as a11y— “a” followed by 11 letters and “y”) means creating digital experiences that anyone can perceive, understand, navigate, and interact with — including people with visual, auditory, motor, or cognitive disabilities.
The 4 POUR Principles
Sight, Hearing & Touch
Information and UI components must be presentable to users in ways they can perceive (e.g. text alternatives for images, captions for video, high color contrast).
Full Keyboard Control
Users must be able to operate the interface (all buttons, forms, and menus reachable via keyboard Tab/Enter/Space without getting trapped).
Clear & Predictable
Content must be readable with clear language, predictable navigation flows, and descriptive form validation error guidance.
Assistive Compatibility
Content must be robust enough that it can be reliably interpreted by screen readers (NVDA, VoiceOver, JAWS) across modern browsers.
Semantic HTML & Page Landmarks
HTML5 landmark elements provide instant navigational jump points for screen reader users:
<header>
<nav aria-label="Main Navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/courses">Courses</a></li>
</ul>
</nav>
</header>
<main id="main-content">
<h1>Accessible Web Architecture</h1>
<article>
<h2>Semantic Landmarks</h2>
<p>Using native HTML elements.</p>
</article>
</main>
<footer>
<p>© 2026 Pathubs</p>
</footer>Keyboard Focus & Accessible Forms
Removing outlines with * { outline: none; } blinds keyboard-only users. Instead, use modern :focus-visible to provide high-visibility focus rings only when navigating via keyboard!
<form>
<div>
<label htmlFor="user-email">Work Email (Required)</label>
<input
id="user-email"
type="email"
required
aria-describedby="email-hint"
/>
<span id="email-hint" className="hint-text">
We'll send your invoice to this address.
</span>
</div>
<button type="submit">Complete Registration</button>
</form>WAI-ARIA: When and When NOT to Use ARIA
No ARIA is better than bad ARIA.ARIA does not add keyboard functionality or change browser behavior — it only modifies accessibility tree metadata. Always use native semantic HTML first!
Accessibility Checklist & Rules of Thumb
- Use
<button>for actions and<a>for page navigation. - Ensure all interactive elements have visible
:focus-visibleindicators. - Always connect
<label for="id">with form inputs. - Provide meaningful
alttext or mark decorative images withalt="". - Verify a minimum 4.5:1 text contrast ratio (WCAG AA).
- Trap focus inside open modal dialogs and allow dismissal via the Escape key.
🔥 Live Interactive — Accessibility Audit Lab
Fix an intentionally broken, inaccessible webpage by applying semantic HTML, keyboard focus, form labels, and WCAG contrast.
❌ Low Contrast Text (1.8:1 ratio — Fails WCAG AA standards)
Test your accessibility architectural choices in these common real-world scenarios.