Web accessibility is not just about following legal requirements — it is about building websites that work for everyone. With accessibility laws tightening across Europe and the EU European Accessibility Act taking effect, WCAG compliance is not optional. Yet WebAIM's annual analysis shows that 96.3 percent of the top one million websites have WCAG failures (WebAIM, "The WebAIM Million," 2025). This guide gives you a practical checklist you can actually use.
Why accessibility matters: Legal requirements and business case
In Norway, web accessibility is regulated by the Universal Design of ICT regulation, requiring all public-facing websites to meet WCAG 2.1 Level AA. The Norwegian Digitalisation Agency enforces compliance and can impose fines for violations. Since 2025, the EU European Accessibility Act (EAA) also requires private sector compliance across Europe.
The business case is as strong as the legal requirement. Approximately 15-20 percent of the population has some form of disability (WHO, "World Report on Disability"). Poor accessibility directly excludes potential customers. Additionally, accessibility improvements enhance SEO (better semantic HTML, alt text), performance (simpler DOM), and general usability for everyone.
A study by Nucleus Research showed that accessible websites have on average 50 percent lower bounce rates than inaccessible ones (Nucleus Research, "The Business Case for Digital Accessibility"). Accessibility is not a cost — it is an investment in better user experience for all. For more on UX design, see our UX design guide.
WCAG 2.1 AA: The four principles
Web Content Accessibility Guidelines (WCAG) are organized around four principles — POUR: Perceivable, Operable, Understandable, and Robust. Each principle has specific success criteria at three levels: A (minimum), AA (recommended standard), and AAA (highest level).
WCAG 2.1 AA is the legally required level in Norway and the EU. It includes all A and AA criteria, totaling 50 success criteria. WCAG 2.2, released in October 2023, adds nine new criteria, primarily targeting mobile users, cognitive disabilities, and authentication.
Understanding the four principles is more important than memorizing individual success criteria. When you design or build, ask yourself these questions: Can the user perceive this content? Can the user navigate and interact with it? Is it understandable? Does it work across technologies and assistive devices?
Color contrast requirements and tools
WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). For non-text UI components and graphical elements, 3:1 contrast against the background is required. These requirements apply to all states — including hover, focus, and active.
Common failures include light gray text on white backgrounds, colored text on colored backgrounds without sufficient contrast, and placeholder text in form fields that is too light. Particularly problematic are CTA buttons where white text on a light color background may look modern but fails the contrast requirement.
Use these tools to check contrast: WebAIM Contrast Checker (web-based, quick check), Figma plugins like Stark or A11y - Color Contrast Checker (during design), Chrome DevTools color contrast tool (during development), and Colour Contrast Analyser by TPGi (desktop app for precise measurement).
- Normal text: Minimum 4.5:1 contrast against background
- Large text (18pt / 14pt bold): Minimum 3:1
- UI components and graphical elements: Minimum 3:1
- Do not rely on color alone to convey information
- Test all states: default, hover, focus, active, disabled
- Tools: WebAIM Contrast Checker, Stark, Chrome DevTools
Keyboard navigation: Focus, tab order, and keyboard traps
All interactive elements must be accessible via keyboard. This means users should be able to navigate with Tab, activate with Enter/Space, and use arrow keys in menus and similar components. The focus indicator — the visible marker showing which element is active — should be clear and never removed with CSS outline: none without a replacement.
Tab order should follow the visual reading order. Use semantic HTML order rather than tabindex manipulation. A skip-to-content link should be the first focusable element, allowing keyboard users to skip past the navigation menu and go directly to the main content.
Keyboard traps — situations where the user cannot navigate away from an element with keyboard — are a critical WCAG failure. Common keyboard traps include modal dialogs without Escape dismissal, third-party widgets with internal keyboard navigation that do not release focus, and autoplay videos that capture focus. Always test the entire user journey with keyboard only.
Screen reader compatibility: Semantic HTML, ARIA, and alt text
Screen readers like NVDA, JAWS, and VoiceOver interpret the page based on HTML structure, not visuals. Semantic HTML — using proper HTML elements like nav, main, article, section, header, footer — is the foundation. A visually perfect page built with only div elements is useless for screen reader users.
ARIA attributes (Accessible Rich Internet Applications) supplement semantic HTML where native elements fall short. Use aria-label for elements without visible text, aria-describedby for additional information, aria-expanded for collapsible sections, and role attributes for custom widgets. But remember the rule: "No ARIA is better than bad ARIA." Use native HTML first.
Alt text for images is its own discipline. Decorative images should have empty alt text (alt=""), not a missing alt attribute. Informative images should have descriptive alt text that conveys the image's function, not just its appearance. An image of a chart should describe the data, not "image of a chart." For complex images, use aria-describedby with a longer description.
- Use semantic HTML5 elements: nav, main, article, section, aside
- Define landmark regions for screen reader navigation
- Alt text: Describe function, not just appearance
- Decorative images: alt="" (empty but present)
- ARIA: Use only when native HTML does not cover the need
- Test with actual screen reader — automated tools catch only 30-40% of issues
Form accessibility: Labels, error messages, and autocomplete
Forms are the most critical interaction surface for accessibility. Every input field must have a programmatically associated label — either with a label element and for attribute, or with aria-label/aria-labelledby. Placeholder text is not a replacement for labels because it disappears when the user starts typing.
Error messages should be specific, associated with the correct field, and announced to screen readers. Use aria-invalid="true" on the field with an error, and aria-describedby to link the error message to the field. Generic error messages like "The form contains errors" are insufficient — the user must know exactly what is wrong and how to fix it.
Autocomplete support with the autocomplete attribute helps all users but is especially important for people with motor or cognitive disabilities. Use autocomplete="name", autocomplete="email", autocomplete="tel" and similar. WCAG 2.1 criterion 1.3.5 explicitly requires this for personal user data.
Media accessibility: Captions, transcripts, and audio descriptions
Video with audio requires captions as a synchronized text alternative. For pre-recorded video, this is an AA requirement. Captions should include not just dialogue but also relevant sound effects and music descriptions. YouTube and Vimeo offer automatic captions, but quality varies — manual correction is necessary for professional content.
Audio-only content (podcasts, interviews) requires text transcription. For pre-recorded video, audio description is also required at AA level — an additional audio track describing important visual information between dialogue. This is demanding to produce but essential for blind users.
For live content, requirements are lighter at AA level — real-time captions are an AAA requirement. But good practice suggests important live events should have captioning. Autoplay of audio or video is problematic for screen reader users and should be avoided, or at least have clear controls to stop/pause.
Responsive and touch-friendly design for accessibility
Mobile accessibility has its own challenges. WCAG 2.1 added several criteria specifically for mobile: touch targets should be at least 44x44 CSS pixels (2.5.5, AAA) or 24x24 (2.5.8, AA in WCAG 2.2), content should work in all orientations (portrait and landscape), and complex gestures should have simple alternatives.
Text size should be enlargeable to 200 percent without loss of content or functionality. Use relative units (rem, em) instead of pixels for font sizes. Test with browser zoom and OS-level text size adjustment on mobile. Content that breaks or overlaps when enlarged is an accessibility failure.
For a deeper review of responsive design, see our web design and CRO guide. Good responsive design is the very foundation of mobile accessibility, and it starts with building for the smallest screen first. Also see our performance guide for how performance affects the accessibility experience.
Testing tools: axe DevTools, Lighthouse, WAVE, and screen readers
Automated testing tools typically catch 30-40 percent of WCAG failures (GDS Accessibility Team, UK Government). They are essential as a first step but do not replace manual testing. The best automated tools are axe DevTools (Deque) — the most accurate engine with Chrome extension and CI integration, Lighthouse — built into Chrome DevTools with accessibility score, and WAVE (WebAIM) — visual overlay showing errors directly on the page.
Manual testing with a screen reader is irreplaceable. For Windows, NVDA (free) is the most widely used testing tool. For Mac and iOS, VoiceOver is built in. Test at least these scenarios: navigate the entire page with keyboard only, read the entire page with screen reader, fill out all forms with screen reader, and activate all interactive elements.
Integrate accessibility checks into the development process: axe-core in CI/CD pipeline, eslint-plugin-jsx-a11y for React projects, and Pa11y for automated browser-based tests. At LeapJet, we run automated accessibility checks on every deploy to catch regressions early.
- axe DevTools: Most accurate, Chrome extension + CI integration
- Lighthouse: Built into Chrome, quick overview with score
- WAVE: Visual overlay, great for designers and non-developers
- NVDA: Free screen reader for Windows, essential for manual testing
- VoiceOver: Built into Mac/iOS, test with Cmd+F5
- Pa11y: Automated testing in CI/CD pipeline
- eslint-plugin-jsx-a11y: Linting for React accessibility
Accessibility checklist: 30+ checkpoints grouped by principle
This checklist covers the most important WCAG 2.1 AA checkpoints organized by the four principles. Use it as a starting point for an accessibility review of your website. For each point: test manually, verify with automated tools where possible, and document status.
Accessibility work is a continuous process, not a one-time job. Integrate these checkpoints into your design, development, and QA processes. For professional help with accessibility auditing and implementation, see our web design services page. Also see our glossary for definitions of accessibility, WCAG, responsive design, and UX.
- PERCEIVABLE: Alt text on all informative images
- PERCEIVABLE: Captions on all video with audio
- PERCEIVABLE: Color contrast 4.5:1 (text) and 3:1 (large text)
- PERCEIVABLE: Do not use color alone to convey information
- PERCEIVABLE: Content adaptable to 200% zoom without loss
- PERCEIVABLE: Text in real HTML, not as image
- OPERABLE: All functionality accessible via keyboard
- OPERABLE: Visible focus indicator on all interactive elements
- OPERABLE: Skip-to-content link as first element
- OPERABLE: No keyboard traps
- OPERABLE: Page titles are descriptive and unique
- OPERABLE: Link text is meaningful out of context
- OPERABLE: Touch targets at least 24x24px (WCAG 2.2)
- OPERABLE: Animations can be paused or stopped
- UNDERSTANDABLE: Page language set in HTML lang attribute
- UNDERSTANDABLE: Navigation is consistent across pages
- UNDERSTANDABLE: Form fields have visible labels
- UNDERSTANDABLE: Error messages are specific and linked to correct field
- UNDERSTANDABLE: Autocomplete used for personal data fields
- UNDERSTANDABLE: Instructions do not rely on sensory characteristics
- ROBUST: HTML is valid and well-formed
- ROBUST: ARIA attributes used correctly
- ROBUST: Custom widgets have correct role and state
- ROBUST: Status messages communicated to screen readers
- ROBUST: Third-party content (iframes, widgets) is accessible
- MOBILE: Content works in portrait and landscape
- MOBILE: Touch targets have sufficient size and spacing
- MOBILE: Gestures have simple alternatives
- TEST: Entire user journey tested with keyboard only
- TEST: Entire user journey tested with screen reader
- TEST: Automated accessibility testing in CI/CD
