Web Accessibility Checklist: Make Your Website WCAG Compliant

Web accessibility is not a nice-to-have feature. It is a fundamental requirement for reaching your full audience, meeting legal obligations, and building a website that works for everyone. Over one billion people worldwide live with some form of disability, and many of them rely on assistive technologies to use the web. When your website is not accessible, you are excluding a significant portion of your potential visitors, customers, and users.

This guide provides a practical checklist based on the Web Content Accessibility Guidelines (WCAG) 2.1, organized by category with actionable steps you can take today.

Understanding WCAG

The Web Content Accessibility Guidelines are the international standard for web accessibility, developed by the World Wide Web Consortium (W3C). WCAG organizes its requirements around four principles, often remembered by the acronym POUR.

Perceivable

Information and interface components must be presentable to users in ways they can perceive. This means content cannot depend on a single sense alone. If information is visual, there must be a text alternative. If it is auditory, there must be captions.

Operable

Interface components and navigation must be operable by all users. This means every interaction must be possible without a mouse, without time pressure, and without triggering seizures or physical reactions.

Understandable

Information and interface operation must be understandable. This means text must be readable, pages must behave predictably, and users must be helped to avoid and correct mistakes.

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means using valid HTML, proper semantic elements, and standardized ARIA attributes.

Conformance Levels

WCAG defines three levels of conformance:

Level A — The minimum level. Failing to meet Level A means your site has significant barriers for people with disabilities.
Level AA — The target for most websites and the standard required by most accessibility laws. This is what you should aim for.
Level AAA — The highest level. Meeting every AAA criterion is not always possible for all content, but individual criteria can be adopted where feasible.

The Accessibility Checklist

Images and Non-Text Content

Every image on your site needs appropriate alternative text. This is one of the most impactful and easiest improvements you can make.

Action items:

Add alt attributes to all <img> elements
Write alt text that describes the image's content or purpose, not just its appearance
Use empty alt text (alt="") for purely decorative images so screen readers skip them
Provide text alternatives for charts, graphs, and infographics
Ensure image buttons have descriptive alt text explaining their function
Add captions to complex images like diagrams or data visualizations

Good alt text: "Bar chart showing website traffic growth from 10,000 to 50,000 monthly visitors between January and December 2025"

Bad alt text: "chart.png" or "image" or "graph"

Color and Contrast

Color contrast affects readability for everyone but is critical for users with low vision or color blindness.

Action items:

Ensure text has a contrast ratio of at least 4.5:1 against its background (Level AA)
Large text (18pt or 14pt bold) requires at least 3:1 contrast ratio
Do not use color as the only way to convey information (for example, "fields marked in red are required" should also use an icon or text label)
Test your color scheme with color blindness simulators
Ensure link text is distinguishable from surrounding text by more than just color (add underlines or other visual indicators)
Check contrast for UI components like form borders, icons, and focus indicators

Use our Accessibility Checker to automatically scan your pages for contrast issues and other WCAG violations.

Keyboard Navigation

Many users navigate entirely with a keyboard, including people who use screen readers, people with motor disabilities, and power users who prefer keyboard shortcuts.

Action items:

Ensure all interactive elements are reachable via the Tab key
Provide a visible focus indicator on all focusable elements (outlines, highlights, or borders)
Maintain a logical tab order that follows the visual layout of the page
Ensure no keyboard traps where focus gets stuck in a component
Make dropdown menus, modals, and custom widgets operable with keyboard
Add a "Skip to main content" link as the first focusable element on each page
Test your entire site by navigating with only a keyboard (no mouse)

Forms and Input

Forms are critical interaction points that are often inaccessible. An inaccessible form can completely block users from completing essential tasks.

Action items:

Associate every form field with a label using the for attribute
Do not rely solely on placeholder text as labels (placeholders disappear when typing)
Group related form fields with <fieldset> and <legend> elements
Provide clear error messages that identify the field and describe the problem
Position error messages near the fields they relate to
Do not require specific formats without explaining them (show "MM/DD/YYYY" rather than just rejecting bad dates)
Ensure form validation works without JavaScript (progressive enhancement)
Make required fields obvious with both visual indicators and aria-required="true"

Headings and Document Structure

Proper document structure helps screen reader users understand and navigate your content.

Action items:

Use heading elements (H1-H6) in a logical, hierarchical order
Do not skip heading levels (do not jump from H2 to H4)
Use only one H1 per page, describing the page's main topic
Do not use headings purely for visual styling (use CSS instead)
Use semantic HTML elements: <nav>, <main>, <article>, <aside>, <footer>
Structure content with lists (<ul>, <ol>) where appropriate
Use <table> elements for tabular data with proper headers (<th>)

Links and Navigation

Navigation accessibility determines whether users can find and access your content.

Action items:

Write descriptive link text that makes sense out of context ("Read the accessibility guide" not "Click here")
Avoid generic link text like "click here," "read more," or "learn more" without additional context
Indicate when links open in a new window or tab
Ensure navigation is consistent across pages
Provide multiple ways to reach content (navigation menu, site search, sitemap)
Use aria-current="page" to indicate the current page in navigation

Multimedia and Video

Audio and video content needs alternatives for users who cannot see or hear it.

Action items:

Provide captions for all video content
Provide audio descriptions for video content where visual information is not described in the audio track
Provide transcripts for audio-only content (podcasts, audio recordings)
Ensure media players are keyboard accessible
Do not auto-play audio or video
Provide controls to pause, stop, and adjust volume

Motion and Animation

Animations and motion can cause serious problems for people with vestibular disorders, seizure conditions, or attention difficulties.

Action items:

Respect the prefers-reduced-motion media query in your CSS
Provide controls to pause or stop any moving, blinking, or scrolling content
Avoid content that flashes more than three times per second
Do not use parallax scrolling without a reduced-motion alternative
Ensure carousel and slider controls are accessible and include pause functionality

ARIA and Semantic HTML

ARIA (Accessible Rich Internet Applications) attributes supplement HTML to make dynamic content accessible. However, the first rule of ARIA is: do not use ARIA if native HTML can do the job.

Action items:

Use native HTML elements whenever possible (<button> instead of <div role="button">)
Add ARIA labels to elements that lack visible text labels
Use aria-live regions for content that updates dynamically
Mark required form fields with aria-required="true"
Use aria-expanded for collapsible sections and menus
Test ARIA implementation with actual screen readers, not just automated tools

Mobile Accessibility

Mobile accessibility has unique considerations beyond desktop accessibility.

Action items:

Ensure touch targets are at least 44x44 CSS pixels
Support both portrait and landscape orientations
Do not disable pinch-to-zoom (user-scalable=no)
Ensure gestures have alternative single-pointer actions
Test with mobile screen readers (VoiceOver on iOS, TalkBack on Android)

Testing Your Accessibility

Automated Testing

Automated tools catch approximately 30-40% of accessibility issues. They are excellent for finding technical violations like missing alt text, insufficient contrast, and invalid ARIA attributes.

Our Accessibility Checker scans your pages for common WCAG violations and provides specific guidance on how to fix each issue. Run it on every page template and any page with unique layouts or interactive features.

Other automated tools include browser extensions like axe DevTools and Lighthouse accessibility audits built into Chrome DevTools.

Manual Testing

Automated tools cannot catch everything. Manual testing is essential for issues like:

Logical reading order and content flow
Quality and helpfulness of alt text
Keyboard focus management in complex interactions
Whether error messages are clear and helpful
Whether custom widgets behave as expected with assistive technology

Screen Reader Testing

Test your site with actual screen readers. The most common combinations are:

NVDA with Firefox (Windows) — Free and open source
JAWS with Chrome or Edge (Windows) — Commercial, widely used in workplaces
VoiceOver with Safari (Mac/iOS) — Built into Apple devices
TalkBack with Chrome (Android) — Built into Android devices

You do not need to master every screen reader, but spending an hour navigating your site with one will reveal issues that no automated tool can detect.

User Testing

The most valuable accessibility testing comes from people with disabilities using their own assistive technologies. If possible, include users with disabilities in your testing process. Their real-world experience reveals practical barriers that theoretical testing misses.

Legal Requirements

Web accessibility is legally required in many jurisdictions.

United States

The Americans with Disabilities Act (ADA) has been interpreted by courts to apply to websites. Section 508 requires federal agencies and their contractors to meet accessibility standards. The Department of Justice has clarified that WCAG 2.1 Level AA is the expected standard.

European Union

The European Accessibility Act requires products and services, including websites and mobile apps, to meet accessibility standards. Public sector websites must already comply under the Web Accessibility Directive.

Other Jurisdictions

Canada (Accessibility for Ontarians with Disabilities Act), UK (Equality Act 2010), and Australia (Disability Discrimination Act) all have laws that apply to web accessibility. The trend globally is toward more regulation, not less.

The Business Case for Accessibility

Beyond legal compliance, accessibility makes good business sense.

Larger audience: Accessible websites reach more people, including the 15% of the global population with disabilities and the growing elderly population.

Better SEO: Many accessibility improvements, such as alt text, proper headings, and semantic HTML, directly improve search engine optimization.

Improved usability: Accessibility improvements benefit all users. Captions help people in noisy environments. Good contrast helps people in bright sunlight. Keyboard navigation helps power users.

Reduced legal risk: Proactive accessibility reduces the risk of lawsuits and complaints, which have increased significantly in recent years.

Frequently Asked Questions

What level of WCAG compliance should I aim for?

WCAG Level AA is the standard target for most websites and the level required by most accessibility laws. It balances comprehensive accessibility with practical implementation. Level A is the bare minimum and leaves significant barriers. Level AAA is ideal but not always achievable for all content types.

How much does it cost to make a website accessible?

The cost varies enormously depending on the size and complexity of your site and how far from accessible it currently is. For new sites, building accessibility in from the start adds minimal cost. For existing sites, common fixes like adding alt text, improving contrast, and fixing heading structure can be done quickly. Complex fixes to custom widgets and dynamic content may require more investment.

Can I use an overlay or plugin to make my site accessible?

Accessibility overlay plugins are widely criticized by the accessibility community. They attempt to fix issues with a layer of JavaScript but often introduce new problems, fail to address structural issues, and can interfere with assistive technologies. The only reliable approach is to fix accessibility issues in your actual code. Use our Accessibility Checker to identify issues and address them at the source.

How often should I test for accessibility?

Test accessibility whenever you make significant changes to your site's design, functionality, or content. Include accessibility checks in your development process rather than treating it as a one-time audit. Automated scans should run as part of your CI/CD pipeline, and manual testing should occur at least quarterly.

Is WCAG the only accessibility standard?

WCAG is the most widely referenced standard, but others exist. Section 508 in the US references WCAG. EN 301 549 is the European standard, which also references WCAG. For mobile apps, additional guidelines from Apple and Google supplement WCAG. In practice, meeting WCAG 2.1 Level AA satisfies the requirements of most other standards.