HTML Accessibility
In this page:
Web Accessibility Basics
Web accessibility means designing pages that can be navigated by anyone, regardless of physical or cognitive abilities. Writing semantic, standard HTML code is the foundation of an accessible webpage.
Note: Use native HTML tags (like buttons and links) to inherit built-in keyboard navigation support automatically.
Warning: Styling non-clickable tags (like div or span) to look like buttons makes them completely unusable for keyboard-only users.
Example: Web Accessibility Basics
<button onclick="alert('Clicked')">Click me</button>Semantic HTML Landmarks
Semantic tags (like main, nav, header, and footer) serve as layout landmarks on your webpage. Screen readers use these landmarks to announce structural outlines, allowing users to skip directly to content blocks easily.
Note: Always wrap your main page topic inside a single, clean main tag to help users navigate.
Warning: Overusing plain div tags instead of semantic landmarks can make navigating your page confusing for screen-reader users.
Example: Semantic HTML Landmarks
<header>Site Header</header>
<nav>Navigation</nav>
<main>Main content</main>
<footer>Footer</footer>ARIA Attributes and Roles
ARIA (Accessible Rich Internet Applications) attributes are specialized accessibility tags used to add context to your markup when standard HTML semantics are not enough.
Note: Always use aria-label to describe icon-only buttons that do not contain visible text.
Warning: The first rule of ARIA is: do not use ARIA if a native, semantic HTML tag can handle the job instead.
Example: ARIA Attributes and Roles
<button aria-label="Close dialog">X</button>Keyboard Navigation and Focus Styles
Keyboard-only and visually impaired users rely on the Tab key to navigate webpages chronologically. You must ensure that every interactive element has a visible focus indicator (like a border outline) so users can see where they are on the page.
Note: Use the tabindex attribute to include custom, styled elements in the webpage tab sequence.
Warning: Never use CSS outline: none to hide browser focus outlines without replacing them with custom focus styles.
Example: Keyboard Navigation and Focus Styles
<a href="#" style="outline: 2px solid blue;">Focusable link</a>Color Contrast and Alt Descriptions
Accessibility relies heavily on high color contrast and clear graphic descriptions. Ensure your text has sufficient color contrast against background fills, and always write descriptive alt text for your images.
Note: Aim to maintain a contrast ratio of at least 4.5:1 for regular paragraph text.
Warning: Omitting alt attributes is a major accessibility violation that makes your images invisible to screen readers.
Example: Color Contrast and Alt Descriptions
<p style="color: #000000; background-color: #FFFFFF;">High contrast text</p>
<img src="photo.jpg" alt="A red bicycle leaning against a wall">Skip Links Implementation
A skip link lets keyboard users jump straight from the top of the page to the main content, bypassing a long navigation menu. It is usually hidden visually until it receives keyboard focus, at which point it becomes clearly visible.
Note: Place the skip link as the very first focusable element in the body so it is always the first thing a keyboard user encounters.
Warning: A skip link hidden with display:none cannot receive keyboard focus at all — use an off-screen positioning technique instead.
Example: Skip Links Implementation
<a href="#main-content" style="position: absolute; left: -9999px;">Skip to main content</a>
<main id="main-content">Main content</main>Accessible Form Labels
Every form input needs an associated label so screen readers can announce what the field is for. Wrapping the input inside the label, or connecting them using a matching for and id attribute, both create this essential relationship.
Note: Clicking or tapping directly on a properly connected label should also focus its input — a great way to test if your labels are correctly linked.
Warning: Using only a placeholder as a substitute for a real label is a common mistake — placeholders disappear once typing starts and are not reliably announced by all screen readers.
Example: Accessible Form Labels
<label for="email">Email</label>
<input type="email" id="email" name="email">Accessibility Testing Tools (Lighthouse, axe)
Lighthouse, built directly into Chrome DevTools, and axe, available as a browser extension, both automatically scan a page and flag common accessibility problems like missing alt text or poor color contrast. Automated tools catch many issues quickly, but they cannot replace actually testing with a keyboard and a real screen reader.
Note: Run Lighthouse's accessibility audit early and often during development, not just once right before launch.
Warning: Passing every automated accessibility check does not guarantee a page is actually usable — automated tools typically catch only around a third of real accessibility issues.
Example: Accessibility Testing Tools (Lighthouse, axe)
<!-- Run Chrome DevTools > Lighthouse > Accessibility audit on this page -->
<img src="banner.jpg" alt="Summer sale banner">- Using non-clickable div or span tags to design custom button layouts, breaking keyboard navigation.
- Hiding browser focus outlines using CSS (outline: none) without replacing them with custom focus styles.
- Forgetting to include alt attributes on your image elements, leaving them invisible to screen readers.
- Web accessibility ensures your website can be navigated by anyone, regardless of physical or cognitive abilities.
- Use semantic HTML tags (like buttons and headers) and ARIA attributes to keep your content readable and accessible.
- Ensure all interactive elements can be focused using the keyboard, and maintain high color contrast for clean readability.
Standard accessibility attributes and semantic elements are supported natively by all modern web browsers.
Chapter Quiz — Complete all 11 topics to unlock
0/11 topics done
Complete these topics first: