Summarize this article with:
One in four adults in the U.S. lives with a disability, yet 96.8% of websites fail basic accessibility standards.
Your site might be excluding millions of potential users without you realizing it. Missing alt text, poor color contrast, and broken keyboard navigation create barriers that prevent people from accessing your content.
This web accessibility checklist covers WCAG compliance requirements, testing methods, and implementation priorities. You’ll learn which fixes deliver the biggest impact, how to test with assistive technology, and what Level AA compliance actually requires.
Whether you’re auditing an existing site or building from scratch, these guidelines help you create inclusive digital experiences that work for everyone.
WCAG Standards and Compliance Levels
The Web Content Accessibility Guidelines (WCAG) from the World Wide Web Consortium (W3C) define how to make web content accessible.
Published standards include WCAG 2.1 (June 2018) and WCAG 2.2 (October 2023).
Three conformance levels exist:
- Level A – Basic accessibility features (minimum requirement)
- Level AA – Addresses major barriers (most common legal standard)
- Level AAA – Highest accessibility (not always achievable)
Studies show 98.1% of homepages have detectable WCAG 2 failures, according to WebAIM’s 2024 analysis of 1 million sites.
The Americans with Disabilities Act (ADA) requires compliance for many organizations, though specific technical standards vary by sector.
POUR Principles
WCAG organizes requirements around four principles:
Perceivable – Information must be presentable to users in ways they can perceive.
Operable – User interface components must be operable by all users.
Understandable – Information and operation must be understandable.
Robust – Content must work with current and future technologies, including assistive technology.
Success Criteria by Level
Level A includes 30 success criteria covering basics like keyboard access and text alternatives.
Level AA adds 20 criteria including color contrast ratios of 4.5:1 for normal text.
Level AAA provides 28 additional criteria for enhanced accessibility, including 7:1 contrast ratios.
Essential Accessibility Requirements
What makes an accessibility requirement critical?
Impact on users, WCAG priority level, legal compliance necessity, and implementation effort.
Text Alternatives for Images
Every image needs descriptive alt text so screen readers can convey visual information to blind users.
Decorative images require empty alt attributes (alt=””) to prevent confusion.
Complex images like charts need extended descriptions via aria-describedby or longdesc attributes.
Keyboard Navigation Support
All functionality must work without a mouse. Period.
Keyboard-only users rely on Tab, Enter, Arrow keys, and Escape.
Interactive elements need visible focus indicators with minimum 3:1 contrast against background.
Color Contrast Compliance
Text must meet minimum contrast ratios: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold).
Non-text elements like icons and form borders require 3:1 contrast.
Tools like the color contrast analyzer from TPGi automate checking these ratios.
Form Field Labels
Every input needs a programmatically associated label element.
Placeholder text alone doesn’t meet accessibility standards.
Error messages must identify which fields have problems and suggest corrections.
Semantic HTML Structure
Proper heading hierarchy (h1 through h6) creates document structure for screen readers.
Semantic markup uses elements like nav, main, article, and aside instead of generic divs.
ARIA labels supplement HTML when native semantics aren’t sufficient.
Time-Based Content Controls
Auto-playing content must have pause, stop, or hide controls.
Users need at least 20 seconds per page for timed responses, or the ability to extend time limits.
Animations that flash more than three times per second can trigger seizures and must be avoided.
Keyboard Navigation Standards
Keyboard accessibility ensures users can navigate without a mouse or touchscreen.
Tab order must follow a logical sequence matching visual layout.
Focus Management
Focus indicators show which element is active during keyboard navigation.
Default browser outlines often fail contrast requirements, so custom styles are needed.
Focus should never become trapped in a component without a clear escape method.
Modal dialogs need special handling: focus moves to the modal on open, stays trapped inside, returns to trigger element on close.
Skip Links
Skip navigation links let keyboard users bypass repetitive content like headers and menus.
These links typically appear as the first focusable element, often visually hidden until focused.
Common skip targets include main content, search functionality, and footer information.
Keyboard Shortcuts
Custom keyboard shortcuts must not conflict with assistive technology commands.
Single-character shortcuts pose problems unless they only work when a component has focus.
Users should be able to remap or disable shortcuts.
Interactive Element Requirements
Buttons, links, and form controls must be keyboard accessible by default.
Custom widgets built with divs and spans need tabindex and ARIA roles to become keyboard operable.
JavaScript must handle both click and keyboard events (Enter and Space keys).
Screen Reader Compatibility
Screen readers convert digital text into synthesized speech or refreshable braille.
Popular screen readers include JAWS, NVDA, VoiceOver, and TalkBack.
ARIA Implementation
See the Pen
ARIA Accessible Accordion by Kiri Egington (@kiriegington)
on CodePen.
Accessible Rich Internet Applications (ARIA) attributes communicate roles, states, and properties to assistive technology.
Use native HTML semantics first; add ARIA only when HTML alone is insufficient.
Common ARIA roles include button, navigation, search, alert, and dialog.
ARIA states and properties include aria-label, aria-labelledby, aria-describedby, aria-expanded, and aria-hidden.
Live Regions
Dynamic content changes need announcements through ARIA live regions.
aria-live=”polite” announces changes when the user is idle.
aria-live=”assertive” interrupts immediately for urgent updates.
Status messages, error notifications, and loading indicators all benefit from live regions.
Screen Reader Testing
Testing with actual screen readers reveals problems automated tools miss.
NVDA (free, Windows) and VoiceOver (built into macOS/iOS) provide accessible testing options.
Listen for unclear labels, missing landmarks, illogical reading order, and verbose or confusing announcements.
Hidden Content Management
Content hidden visually must also be hidden from screen readers using aria-hidden=”true”.
Visually hidden but screen reader accessible content uses CSS clip techniques, not display:none.
Skip links and off-canvas menus often need this treatment.
Color Contrast and Visual Design
Color contrast determines whether text remains readable for users with low vision or color blindness.
WCAG Level AA requires 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold).
Level AAA increases these to 7:1 and 4.5:1 respectively.
Contrast Testing Tools
WebAIM’s color contrast checker, axe DevTools, and Lighthouse all measure contrast ratios automatically.
Browser extensions like Colour Contrast Analyser provide real-time feedback during design.
Test contrast for all text, icons, form borders, and focus indicators.
Color-Dependent Information
Never rely solely on color to convey information.
Use patterns, icons, labels, or text alongside color coding.
Charts need textured fills or direct labels, not just color-coded legends.
Design Considerations
Light gray text on white backgrounds frequently fails contrast requirements.
Transparent overlays on images often create insufficient contrast.
Link text needs sufficient contrast against both background and surrounding text.
Form Accessibility
Accessible forms connect labels to inputs programmatically using the for and id attributes.
Error prevention, identification, and correction must all be accessible.
Label Requirements
See the Pen
Accessible Web Form Example by Bogdan Sandu (@bogdansandu)
on CodePen.
Every input, select, and textarea needs an associated label element.
Placeholder text disappears on input and doesn’t replace proper labels.
Fieldset and legend elements group related form controls like radio buttons.
Error Handling
Error messages must identify which field has the problem and why.
Announce errors to screen readers using ARIA live regions or moving focus to the error summary.
Required fields need clear indication beyond color alone.
Input Types and Autocomplete
HTML5 input types (email, tel, url) trigger appropriate mobile keyboards and validation.
Autocomplete attributes help password managers and form autofill features work properly.
Touch targets for form controls need minimum 44×44 pixel hit areas.
Form Validation
Client-side validation provides immediate feedback without page reloads.
Validation messages must be programmatically associated with their controls.
Users need clear instructions before submission, not just after errors occur.
Multimedia Content Requirements
Video and audio content needs alternatives for users who can’t see or hear the material.
Captions, transcripts, and audio descriptions each serve different accessibility needs.
Captions for Video
Closed captions display spoken dialogue and important sound effects as synchronized text.
WCAG Level A requires captions for prerecorded video with audio.
Open captions burn directly into video; closed captions can toggle on/off.
WebVTT format provides the standard for web-based caption files.
Audio Descriptions
Audio descriptions narrate visual information during natural pauses in dialogue.
Required at Level AA for prerecorded video.
Extended audio descriptions pause the video when natural gaps are insufficient.
Transcripts
Text transcripts provide a full text alternative for audio-only content like podcasts.
Video transcripts combine spoken words, sound effects, and visual descriptions.
Transcripts benefit users who prefer reading, need searchable text, or have both hearing and vision impairments.
Media Player Controls
Custom media players need keyboard accessible controls.
Play/pause, volume, seek, and caption toggle must all work without a mouse.
Focus indicators must be clearly visible on all player controls.
Document Accessibility
PDFs, Word documents, and other downloadable files need the same accessibility treatment as web pages.
Many organizations fail to make documents accessible despite having accessible websites.
PDF Accessibility
Tagged PDFs include structural information for screen readers.
Heading hierarchy, reading order, alternative text, and form labels all apply to PDFs.
Adobe Acrobat Pro provides accessibility checking and remediation tools.
Untagged PDFs are essentially images to screen readers—completely inaccessible.
Alternative Formats
Provide HTML versions of documents when possible.
Plain text or accessible Word documents offer alternatives to complex PDFs.
Large documents benefit from breaking into multiple pages with clear navigation.
Document Structure
Use built-in heading styles in Word rather than manually formatted text.
Accessible tables need header rows and simple structures without merged cells.
List formatting should use actual list elements, not manually typed bullets.
Link Text in Documents
“Click here” and “read more” links lack context for screen reader users.
Descriptive link text like “2024 annual report” works better.
URLs spelled out as text should match the actual link destination.
Testing Methods and Tools
Automated testing catches 30-40% of accessibility issues.
Manual testing and real user testing find the rest.
Automated Testing Tools
WAVE browser extension overlays accessibility information directly on pages.
axe DevTools integrates into Chrome and Firefox developer tools.
Lighthouse in Chrome provides accessibility scores and specific recommendations.
Pa11y and aXe-core run command-line tests for continuous integration.
Manual Testing Procedures
Keyboard-only testing reveals navigation and focus problems.
Screen reader testing uncovers labeling and structure issues.
Zoom to 200% without horizontal scrolling tests responsive design.
Grayscale conversion tests color-dependent information.
Browser Testing
Cross-browser compatibility affects accessibility features differently.
Test focus indicators, ARIA support, and keyboard behavior across browsers.
Mobile browsers need separate testing, especially for touch target sizes.
User Testing
Testing with actual users with disabilities reveals real-world problems.
Recruit participants with diverse disabilities (visual, motor, cognitive, auditory).
Observe how assistive technology users interact with your site.
Mobile Accessibility Considerations
Mobile app accessibility and mobile web share many requirements but differ in implementation.
Touch interfaces need different considerations than mouse-and-keyboard setups.
Touch Target Sizing
Minimum touch target size is 44×44 pixels per WCAG 2.1.
WCAG 2.2 increases this to 24×24 pixels minimum with some spacing exceptions.
Closely spaced targets cause accidental activation for users with motor impairments.
Orientation and Motion
Content must work in both portrait and landscape orientations.
Motion-based controls need alternative input methods.
Avoid content that relies on device motion unless absolutely necessary.
Mobile Screen Reader Support
VoiceOver (iOS) and TalkBack (Android) differ in gesture controls and announcement patterns.
Test swipe navigation through page elements.
Ensure custom gestures don’t conflict with screen reader gestures.
Viewport and Zoom
Users must be able to zoom content to 200% without loss of functionality.
Media queries should avoid disabling zoom with maximum-scale=1.0.
Text reflow at zoom levels prevents horizontal scrolling.
Common Accessibility Errors
WebAIM’s annual analysis identifies recurring problems across millions of websites.
Missing Alternative Text
57.3% of home pages have images without alt attributes.
Empty alt on decorative images is correct; missing alt is always wrong.
Complex images need extended descriptions beyond simple alt text.
Low Contrast Text
83.6% of home pages show insufficient color contrast.
Light gray text remains a popular but inaccessible design trend.
Button text and form labels frequently fail minimum contrast requirements.
Empty Links and Buttons
Links without text content confuse screen reader users.
Icon-only buttons need aria-label or screen reader-only text.
Adjacent duplicate links to the same destination create unnecessary clutter.
Missing Form Labels
53.8% of home pages have unlabeled form inputs.
Placeholder text doesn’t replace proper label elements.
Visual positioning alone doesn’t create programmatic associations.
Missing Language Attributes
The lang attribute on the html element helps screen readers pronounce content correctly.
Multi-language content needs lang attributes on specific elements.
Missing language attributes rank among the most common WCAG violations.
Implementation Priority Framework
Not everything can be fixed at once.
Prioritize based on impact, reach, effort, and legal risk.
High Priority Fixes
Keyboard navigation affects many users and often requires significant work.
Missing alternative text on images is easy to fix and high impact.
Form label associations take minimal time but drastically improve usability.
Color contrast failures need design decisions but clear success criteria exist.
Medium Priority Improvements
ARIA implementation for complex widgets requires testing and refinement.
Video captions take time to produce but serve a specific user group.
Focus indicator improvements balance design aesthetics with visibility requirements.
Lower Priority Enhancements
Level AAA improvements go beyond legal requirements for most organizations.
Advanced ARIA patterns for custom components need extensive testing.
Detailed audio descriptions require professional production resources.
Quick Wins
Add lang attributes to HTML elements—takes seconds per page.
Fix empty link text by adding descriptive labels.
Enable keyboard access by removing tabindex=”-1″ from focusable elements.
Add skip links to page templates for immediate navigation benefits.
Accessibility Maintenance and Monitoring
Accessibility isn’t a one-time project.
Content updates, design changes, and new features all risk introducing barriers.
Continuous Testing
Integrate accessibility checks into your deployment pipeline.
Run automated tests with every code commit using tools like Pa11y CI.
Schedule quarterly manual audits for deeper testing.
Content Author Training
Teach content creators to write descriptive alt text and use proper heading hierarchy.
Provide templates and checklists for common content patterns.
Build accessibility checks into your content management system.
Design System Documentation
Document accessibility requirements for each component in your design system.
Include keyboard interactions, ARIA patterns, and focus management in component specifications.
Create accessible component libraries that developers can use directly.
Monitoring and Metrics
Track the number and types of accessibility issues over time.
Monitor user feedback specifically about accessibility barriers.
Review analytics for unusually high bounce rates that might indicate accessibility problems.
FAQ on Web Accessibility Checklist
What is a web accessibility checklist?
A web accessibility checklist is a structured list of requirements ensuring websites work for users with disabilities. It covers WCAG standards, keyboard navigation, screen reader compatibility, color contrast, and form accessibility to create inclusive digital experiences.
Why is web accessibility important?
Web accessibility ensures equal access for people with disabilities, expands your audience, reduces legal risk, and improves SEO. Sites meeting WCAG 2.1 Level AA standards comply with ADA requirements and serve users who rely on assistive technology.
What are the most common accessibility violations?
Missing alternative text, insufficient color contrast, unlabeled form inputs, broken keyboard navigation, and empty links represent the most frequent violations. WebAIM’s analysis shows 96.8% of home pages contain detectable WCAG failures in these areas.
How do I test my website for accessibility?
Use automated tools like WAVE, axe DevTools, and Lighthouse for initial scanning. Follow with manual keyboard testing, screen reader evaluation using NVDA or VoiceOver, and zoom testing to 200%. User testing with disabled participants reveals real-world issues.
What is WCAG compliance?
WCAG (Web Content Accessibility Guidelines) defines technical standards for accessible web content. Level A covers basic requirements, Level AA addresses major barriers and satisfies most legal standards, while Level AAA provides enhanced accessibility for specialized contexts.
Do all images need alt text?
Every image needs an alt attribute. Informative images require descriptive text; decorative images use empty alt=”” attributes. Complex images like charts need extended descriptions through aria-describedby. Missing alt attributes always fail WCAG compliance regardless of image purpose.
What color contrast ratio is required?
Normal text requires 4.5:1 contrast minimum; large text (18pt+ or 14pt+ bold) needs 3:1. Non-text elements like icons require 3:1 contrast. Level AAA increases these to 7:1 and 4.5:1 respectively for enhanced accessibility.
How do I make forms accessible?
Connect every input to a label using for and id attributes. Provide clear error messages with specific corrections. Use appropriate input types for mobile keyboards. Mark required fields with text, not just color. Group related controls with fieldset and legend.
What are ARIA attributes?
ARIA (Accessible Rich Internet Applications) attributes communicate roles, states, and properties to assistive technology. Common examples include aria-label, aria-expanded, aria-live, and role attributes. Use native HTML semantics first; add ARIA only when HTML alone proves insufficient.
Can I automate accessibility testing completely?
Automated tools catch 30-40% of issues but miss context-dependent problems. Manual keyboard testing, screen reader evaluation, and user testing remain necessary. Combine automated scanning in your deployment pipeline with quarterly manual audits for comprehensive coverage.
Conclusion
Implementing a web accessibility checklist transforms your website from exclusive to inclusive. Start with high-impact fixes: keyboard navigation, alternative text, form labels, and color contrast ratios.
WCAG 2.1 Level AA compliance isn’t just about avoiding ADA lawsuits. It’s about reaching the 1.3 billion people worldwide who experience disabilities.
Automated testing tools like axe DevTools and WAVE catch basic violations quickly. Manual testing with screen readers like NVDA and VoiceOver reveals deeper issues that algorithms miss.
Accessibility maintenance never ends. New content, design updates, and feature additions all risk introducing barriers.
Build accessibility checks into your deployment pipeline. Train content authors on semantic HTML and ARIA implementation. Make inclusive design your default, not an afterthought.
Every user deserves equal access to your digital content.
