Website Accessibility Checklist
Building an inclusive web: WCAG compliance, screen readers, and keyboard navigation.
Web accessibility (a11y) is not just a nice-to-have feature; it is a fundamental requirement for a modern website. Designing and developing with accessibility in mind ensures that everyone, including people with visual, auditory, motor, or cognitive disabilities, can perceive, understand, navigate, and interact with your content. Ignoring accessibility often leads to legal repercussions and actively excludes a significant portion of your potential audience.
This checklist expands on the accessibility section of our Ultimate Website Launch Checklist. Before your site goes live, use these guidelines to ensure you meet or exceed WCAG (Web Content Accessibility Guidelines) 2.1 AA standards. This guide covers the critical technical implementations required for full keyboard navigation and robust screen reader support.
Related Technical Guides:
1. The Foundation: Semantic HTML
The most powerful tool in your accessibility arsenal is native, semantic HTML. Screen readers rely heavily on the underlying markup to understand the structure and purpose of a document.
Document Structure Landmarks
Use native HTML5 landmark elements to define the major sections of your page: `<header>`, `<nav>`, `<main>`, `<article>`, `<aside>`, and `<footer>`. Screen reader users often use these landmarks to quickly jump to the content they care about, bypassing repetitive navigation links.
Logical Heading Hierarchy
Headings (`<h2>` through `<h6>`) must form an outline of your content. Never skip heading levels (e.g., jumping from an H2 directly to an H4). Screen readers allow users to navigate pages by heading level, so an illogical structure makes it incredibly difficult to understand the context of the content. Every page should have exactly one `<h2>` that describes its main topic.
Meaningful Alt Text for Images
Every `<img>` tag must include an `alt` attribute. If an image conveys meaning or information, the alt text must succinctly describe that content. If an image is purely decorative (e.g., a background flourish or a spacer), include an empty alt attribute (`alt=""`). This explicitly tells the screen reader to ignore the image. Without an empty alt attribute, some screen readers will annoyingly read the entire file name aloud.
2. Operability: Keyboard Navigation
A significant portion of users rely entirely on a keyboard (or a keyboard emulator) to navigate the web. If a user cannot use a mouse, they must still be able to interact with every feature of your site.
The `Tab` Order
Ensure that users can navigate through all interactive elements (links, buttons, form fields) using the `Tab` key (and `Shift+Tab` to go backward). The DOM order must match the visual order of the page. Avoid manipulating the visual order with CSS properties like `float` or `flex-direction: row-reverse` if it causes the logical tab order to become confusing and disjointed.
Visible Focus States
It is absolutely critical that keyboard users know which element currently has focus. Never remove the default browser focus outline (`outline: none;`) unless you replace it with a highly visible custom focus state (e.g., `outline: 2px solid var(--accent-color); outline-offset: 2px;`). Ensure the focus state has a contrast ratio of at least 3:1 against the surrounding background.
Skip to Content Links
Implement a "Skip to Main Content" link as the very first focusable element on the page. This is usually hidden visually but becomes visible when it receives keyboard focus. It allows keyboard users to bypass long, repetitive navigation menus and jump straight to the `<main>` content area.
Keyboard Event Listeners
If you build custom interactive components (like a modal, dropdown, or custom slider), you must implement the appropriate keyboard event listeners. Native HTML `<button>` and `<a>` elements handle `Enter` and `Space` key activations automatically. If you use a `<div>` as a button (which is strongly discouraged), you must explicitly handle these events via JavaScript.
3. Perceivability: Color and Contrast
Design choices significantly impact usability for users with low vision, color blindness, or situational impairments (like glaring sunlight on a screen).
WCAG Contrast Ratios
Ensure all text meets the WCAG AA contrast ratio requirements. Normal text (typically below 18pt or 14pt bold) requires a contrast ratio of at least 4.5:1 against its background. Large text requires a ratio of at least 3:1. This rule applies to text overlaid on images or gradients as well.
Don't Rely Solely on Color
Color should never be the only means of conveying information, indicating an action, or prompting a response. For example, if a form field is invalid, don't just turn the border red; include an explicit error message and an icon to convey the failure state to color-blind users.
4. Understandability: Forms and ARIA
Complex, dynamic UI patterns often require additional help to be understood by assistive technologies.
Explicit Form Labels
Every form `<input>`, `<textarea>`, and `<select>` element must be explicitly associated with a `<label>`. Use the `for` attribute on the label to reference the `id` of the input. Do not rely solely on placeholder text, as it disappears when the user starts typing and often has poor color contrast.
Strategic Use of ARIA
Accessible Rich Internet Applications (ARIA) attributes bridge the gap when native HTML isn't enough. Use `aria-expanded` on accordion buttons, `aria-hidden="true"` to hide decorative icons from screen readers, and `aria-live` regions to announce dynamic content updates (like a form submission success message) without requiring a page reload. However, remember the first rule of ARIA: No ARIA is better than bad ARIA. Always prefer native HTML elements when available.