Improving Web Accessibility with WCAG 2.1 Compliance

Why accessibility matters—and why WCAG 2.1 is your roadmap

An accessible web is good for users and good for business. It reduces friction, expands your audience, strengthens brand trust, and lowers legal risk. But even teams with the best intentions can struggle to translate “accessibility” into day-to-day decisions.

WCAG 2.1 (Web Content Accessibility Guidelines) is your practical, globally recognized playbook. It builds on WCAG 2.0 to better address low vision, cognitive and learning needs, and mobile/touch interactions—areas that reflect how people actually browse today.

This guide turns WCAG 2.1 into clear, actionable steps you can apply to design systems, content workflows, and development practices. You’ll learn what the standard asks for—and how to implement it efficiently across real websites and products.

The foundation: POUR and conformance levels

WCAG is built around four principles (POUR). Content must be:

• Perceivable: Users can perceive content with available senses (e.g., screen readers, color contrast).
• Operable: Users can operate the interface (e.g., keyboard, touch, no traps).
• Understandable: Users can comprehend and predict interactions (e.g., clear labels, consistent navigation).
• Robust: Content works with current and future user agents and assistive tech (e.g., semantics, ARIA).

Conformance levels:

• Level A: Baseline accessibility requirements.
• Level AA: The recommended standard for most organizations and legal frameworks (ADA, Section 508, EN 301 549 typically align to AA).
• Level AAA: Highest standard; many criteria are aspirational or context-dependent.

WCAG 2.1 adds success criteria that support:

• Mobile and touch (pointer gestures, orientation, target sizes).
• Low vision (reflow, text spacing, non-text contrast).
• Cognitive/learning needs (consistent input purpose, content on hover/focus, status messages).

What changed in WCAG 2.1—key additions to know

Some of the most impactful 2.1 criteria include:

• 1.3.4 Orientation (AA): Don’t lock content to one orientation.
• 1.3.5 Identify Input Purpose (AA): Use programmatic hints (like autocomplete) for common fields.
• 1.4.10 Reflow (AA): Support viewing at 320 CSS pixel width without horizontal scrolling for text content.
• 1.4.11 Non-text Contrast (AA): 3:1 contrast for UI components, controls, and graphic objects carrying meaning.
• 1.4.12 Text Spacing (AA): Don’t break when users adjust spacing.
• 1.4.13 Content on Hover or Focus (AA): Provide dismissible, hover/focus-triggered content that stays visible and is hoverable/focusable.
• 2.5.1 Pointer Gestures (A): Provide simple single-pointer alternatives to complex gestures.
• 2.5.2 Pointer Cancellation (A): Avoid accidental triggers—allow cancellation/undo.
• 2.5.3 Label in Name (A): Visible label text should match accessible name (e.g., for voice control).
• 2.5.4 Motion Actuation (A): Offer alternatives to shaking/tilting; let users disable motion activation.
• 4.1.3 Status Messages (AA): Programmatically convey success, error, and status messages without moving focus.

Note on target size: WCAG 2.1’s 2.5.5 Target Size is AAA. If you’re aiming AA compliance, treat 44 × 44 px touch targets as a strong best practice (and a requirement if you plan for WCAG 2.2 AA later).

Plan accessibility early: design and content first

Accessibility is faster and cheaper when you bake it into design and content:

• Create an accessible color palette with WCAG-compliant contrast.
• Define patterns: focus styles, error states, buttons, forms, modal, and navigation.
• Use design tokens to enforce color, spacing, and type scale that meet WCAG.
• Provide content guidelines: plain language, meaningful link text, descriptive alt text, and heading hierarchy.
• Include accessibility acceptance criteria in user stories and QA checklists.
• Co-design with users with disabilities where possible; test with real assistive technologies.

Structure and semantics: the skeleton of accessibility

Good structure helps both assistive technology and your future self.

• Use one H1 per page and a logical heading hierarchy (H2 for sections, H3 for subsections).
• Mark up lists, quotes, tables, and code semantically—avoid purely visual constructs.
• Use landmark roles/regions to help screen reader users jump quickly:
  • header, nav, main, aside, footer
  • Complement with ARIA roles when native landmarks aren’t present: role="banner" (header), role="navigation", role="main", role="contentinfo".
• Note the page language and inline language shifts:
  • html lang="en" for English pages
  • span lang="es" for Spanish phrases
• Provide a “Skip to main content” link as the first focusable item on the page.

Example skip link:

<a class="skip-link" href="#main">Skip to main content</a>
<header>...</header>
<main id="main">...</main>

CSS to make it visible on focus:

.skip-link {
  position: absolute; left: -999px; top: auto; width: 1px; height: 1px; overflow: hidden;
}
.skip-link:focus {
  position: static; width: auto; height: auto;
  background: #fff; color: #000; padding: .5rem 1rem; z-index: 1000;
}

Color and contrast: make content perceivable

• Text contrast (1.4.3 AA):
  • 4.5:1 for normal text
  • 3:1 for large text (18.66px/14pt bold or 24px/18pt regular)
• Non-text contrast (1.4.11 AA):
  • 3:1 for component boundaries and meaningful graphics (e.g., chart lines).
• Don’t use color alone to convey meaning (1.4.1 A). Add icons, labels, or patterns.

Practical tips:

• Build a contrast matrix during design; test using tools like Axe, WAVE, or Contrast.
• For charts, combine color with pattern/texture and direct labels.
• Ensure placeholder text is not the only instruction; make labels visible.

Images and media: write for screen readers and beyond

• Informative images: Provide meaningful alt text that conveys the purpose, not just description.
• Decorative images: Empty alt attribute alt="" and no role="img" to skip.
• Complex images (charts, diagrams): Provide a short alt plus a longer description via adjacent text or aria-describedby.

Examples:

<!-- Informative -->
<img src="team.jpg" alt="Customer support team smiling at their desks">

<!-- Decorative -->
<img src="divider.svg" alt="" role="presentation">

<!-- Complex chart with description -->
<figure>
  <img src="sales-chart.png" alt="Bar chart of quarterly sales by region">
  <figcaption id="chart-desc">
    Q1–Q4 sales increased 28% in the North region, 12% in the East; South and West remained flat.
  </figcaption>
</figure>

Time-based media:

• Captions for videos with audio (1.2.2 AA).
• Audio descriptions for important visuals when needed (1.2.5 AA).
• Transcripts for audio-only content (1.2.1 A).
• No auto-play with sound; if unavoidable, give a clear pause/stop control (2.2.2 A).

Keyboard access and focus management

Keyboard operability is non-negotiable.

• Make all interactive components reachable via Tab and operable with keyboard (2.1.1 A).
• Logical focus order that follows the visual order (2.4.3 A).
• Visible focus state (2.4.7 AA). Don’t remove outlines; if restyling, ensure high contrast and clear shape.

CSS example:

:focus {
  outline: 3px solid #1a73e8; outline-offset: 2px;
}

Avoid keyboard traps (2.1.2 A). For modals:

• Move focus into the modal on open.
• Trap focus within the modal while it’s open.
• Restore focus to the trigger on close.
• Use role="dialog" aria-modal="true" and an accessible name.

Modal markup pattern:

<button id="open">Open dialog</button>
<div id="dialog" role="dialog" aria-modal="true" aria-labelledby="title" hidden>
  <h2 id="title">Subscribe to updates</h2>
  <form>...</form>
  <button id="close">Close</button>
</div>

If you control focus in JavaScript, test with a keyboard-only workflow. Add Escape key handlers to close overlays.

Forms that guide, not confuse

Forms are where users succeed or drop off. Aim for clarity, predictability, and helpful feedback.

• Always use explicit labels (3.3.2 A). Don’t rely on placeholders.
• Associate labels with inputs via for and id.
• Group related fields with fieldset and legend (e.g., shipping method).
• Provide clear instructions and examples up front (3.3.2 A).
• Identify required fields programmatically (aria-required="true") and visually.
• Provide helpful error messages and suggestions (3.3.1 A, 3.3.3 AA).
• Avoid relying solely on color to indicate errors—use icons and text.
• Use autocomplete attributes to match known input purposes (1.3.5 AA).
• Ensure visible label text appears in the accessible name for voice input alignment (2.5.3 A).

Accessible form example:

<form novalidate>
  <div>
    <label for="email">Email address</label>
    <input id="email" name="email" type="email" autocomplete="email" required aria-describedby="email-hint">
    <div id="email-hint">We’ll send a confirmation.</div>
  </div>

  <fieldset>
    <legend>Delivery method</legend>
    <div>
      <input type="radio" id="standard" name="delivery" value="standard">
      <label for="standard">Standard (3–5 days)</label>
    </div>
    <div>
      <input type="radio" id="express" name="delivery" value="express">
      <label for="express">Express (1–2 days)</label>
    </div>
  </fieldset>

  <button type="submit">Place order</button>
</form>

Status messages (4.1.3 AA):

• Use polite live regions for validation messages that don’t move focus.

<div role="status" aria-live="polite" id="form-status"></div>

Error prevention for important transactions (3.3.4 AA):

• Provide confirmation screens, easy review, and the ability to correct mistakes before final submission.

Mobile and touch interactions

WCAG 2.1 explicitly addresses mobile behaviors.

• Pointer gestures (2.5.1 A): Provide simple, single-pointer alternatives to complex gestures. Example: Instead of pinch-to-zoom only, provide +/– buttons.
• Pointer cancellation (2.5.2 A): Trigger actions on “up” events and allow cancellation to reduce accidental taps.
• Motion actuation (2.5.4 A): Allow disabling “shake to undo” and provide standard controls.
• Orientation (1.3.4 AA): Don’t force portrait or landscape unless essential (e.g., a game or piano app).
• Touch target size: While 2.5.5 Target Size is AAA in 2.1, use at least 44 × 44 CSS px for tappable elements. Provide adequate spacing to avoid accidental activation.

Practical layout guidance:

• Leave comfortable spacing between interactive elements.
• Ensure controls remain visible and reachable when virtual keyboards open.
• Don’t hide essential controls in hover-only states; touch has no hover. Use focus/press/expanded states that work with keyboard and touch.

Reflow, text spacing, and zoom

Make content work well at different sizes and settings.

• Reflow (1.4.10 AA): Support 320 CSS px width without requiring two-dimensional scrolling for text content. In practice, this means responsive design that avoids fixed-width layouts.
• Resize text (1.4.4 AA): Users should be able to zoom to 200% without loss of content or functionality.
• Text spacing (1.4.12 AA): Content must remain usable if users apply the following minimum spacing:
  • Line height: 1.5 times font size
  • Paragraph spacing: 2 times font size
  • Letter spacing: 0.12 times font size
  • Word spacing: 0.16 times font size

CSS test override (for QA):

html {
  line-height: 1.5 !important;
  letter-spacing: .12em !important;
  word-spacing: .16em !important;
}
p { margin-bottom: 2em !important; }

Content on hover or focus, and moving content

• Content on hover/focus (1.4.13 AA): Tooltips/popovers must be:
  • Dismissible (Esc key or close button),
  • Hoverable/focusable,
  • Persistent until dismissed (doesn’t disappear when moving cursor to it).
• Pause, stop, hide (2.2.2 A): For content that auto-updates, provide controls to pause/stop/hide. Carousels must be pauseable and navigable via keyboard.
• Three flashes or below threshold (2.3.1 A): Avoid flashing content; if necessary, keep below thresholds to prevent seizures.

Accessible tooltip approach:

• Use a button, not hover-only.
• Provide aria-expanded and aria-controls when toggling content.
• Keep tooltip content in the tab order or ensure it can be reached via keyboard.

ARIA: use it wisely and sparingly

First rule of ARIA: use native HTML first. When you need ARIA:

• Name, role, value (4.1.2 A): Ensure components expose a recognized role and accessible name, and support change notifications.
• Live regions for dynamic content:
  • role="status" (polite, no focus)
  • role="alert" (assertive, immediate)
• States and properties (aria-expanded, aria-pressed, aria-current) must reflect visual state.

Accessible button vs. clickable div:

<!-- Bad -->
<div onclick="save()">Save</div>

<!-- Good -->
<button type="button" onclick="save()">Save</button>

Accessible disclosure button:

<button aria-expanded="false" aria-controls="faq-1" id="faq-btn-1">
  What is your refund policy?
</button>
<div id="faq-1" hidden>
  We provide a 30-day refund...
</div>

Update aria-expanded and hidden when toggled, and move focus appropriately when content opens if needed.

Patterns and components: build once, use everywhere

Standardize accessible patterns in your design system:

• Navigation and menus:

  • Keyboard support: Arrow keys for menu items, Esc to close, loop or clamp focus predictably.
  • roles: menubar/menuitem for app menus; for site navs, consider using simple lists with buttons for submenus to reduce complexity.

• Tabs:

  • role="tablist", role="tab", role="tabpanel"
  • Only the active tab is in the tab order; use arrow keys to switch.
  • Each tab controls a labeled panel via aria-controls.

• Accordions:

  • Use buttons with aria-expanded and aria-controls; keep headings inside for structure.

• Carousels:

  • Pause/stop button, keyboard-accessible previous/next, visible focus, reasonable motion, and announce slide changes via aria-live if appropriate.

• Modals:

  • See earlier focus and role guidance; ensure screen reader users know a dialog opened and what its title is.

• Tables:

  • Use th for headers, scope="col|row", and caption for summary.
  • For complex tables, use headers and id attributes or aria-describedby to map cells to headers.

• Notifications:

  • role="status" for non-critical updates; role="alert" for critical.
  • Prefer unobtrusive updates that don’t steal focus.

Content design: clarity, consistency, and cognitive support

• Plain language and short sentences improve comprehension.
• Break long processes into steps and show progress indicators.
• Use descriptive link text—avoid “click here.” Example: “Download the annual report (PDF, 1.2 MB).”
• Keep navigation consistent across pages (3.2.3 AA), and components behaving consistently (3.2.4 AA).
• Provide help and contact options on complex tasks.
• Avoid unexpected context changes on focus or input (3.2.1 A, 3.2.2 A).

Non-HTML content: PDFs and documents

If you must use PDFs or other formats:

• Tag the document for reading order and semantics.
• Provide document language, headings, alt text for images, and proper link annotations.
• Ensure text is selectable; avoid scanned-image PDFs.
• Offer an accessible HTML alternative when possible.

Testing: combine automated checks with human judgment

No single tool can guarantee compliance. Use a multi-layered approach:

Automated tools (quick checks, CI-ready):

• Axe, Pa11y CI, Lighthouse, WAVE, Siteimprove, ARC Toolkit.
• Integrate into build pipelines; fail builds for critical violations.

Manual and assistive tech testing:

• Keyboard-only: Navigate every page and task without a mouse.
• Screen readers:
  • NVDA + Firefox (Windows)
  • JAWS + Chrome/IE (Windows)
  • VoiceOver + Safari (macOS/iOS)
  • TalkBack (Android)
• Zoom and reflow: Test at 200% zoom and at 320 CSS px viewport width.
• Color vision simulations and contrast checks.
• Motion and prefers-reduced-motion testing.
• Touch target spacing on actual devices.

User testing:

• When feasible, include people with disabilities in usability sessions. Their feedback will surface real-world issues tools miss.

Legal, risk, and the business case

• Many jurisdictions align enforcement to WCAG 2.1 AA.
• Accessibility reduces legal exposure, but more importantly:
  • Increases conversions by reducing drop-offs.
  • Improves SEO (semantic HTML, better link structure).
  • Enhances performance and resilience.
  • Expands your market to older users and users with temporary limitations (broken arm, bright sun glare).

Create a policy that states your target conformance level (usually AA), your scope, and your governance process.

Process, governance, and culture

Accessibility scales when it’s systemic.

• Roles and responsibilities:

  • Executive sponsor sets policy and budget.
  • Accessibility lead (or team) sets standards, trains, and audits.
  • Designers own color, type, and interaction patterns.
  • Developers own semantic HTML, keyboard access, and ARIA.
  • QA includes accessibility in every sprint.

• Definition of Done:

  • Includes automated checks passing, keyboard operability, focus visibility, contrast, and basic screen reader checks.

• Training:

  • Regular workshops for design, content, dev, and QA.
  • Playbooks and checklists embedded in workflows.

• Backlog and remediation:

  • Triage by severity and user impact.
  • Fix foundational issues first (navigation, forms, contrast, keyboard).

• Continuous monitoring:

  • Scheduled scans, analytics on errors (e.g., form drop-offs), and user feedback channels.

Writing a WCAG 2.1 conformance claim and accessibility statement

If you publish a conformance claim:

• Specify WCAG version (2.1), level (AA), the scope (pages, subdomains, time period), and known exceptions.
• List technologies relied upon (HTML, CSS, JavaScript, WAI-ARIA).
• Outline testing methods used.

Accessibility statement for your site:

• Your commitment and target conformance level.
• Contact methods for feedback and requests for alternative formats.
• Known limitations and timelines for fixes.
• Date of the last update.

Quick-reference checklist (AA-focused)

Perceivable

• Headings in logical order; landmarks present.
• Alt text on meaningful images; decorative images hidden with alt="".
• Video captions and audio transcripts available.
• Text contrast 4.5:1 (normal), 3:1 (large); UI elements and graphics 3:1.
• Responsive layout supports 320 CSS px reflow, 200% zoom.
• Content remains usable with increased text spacing.

Operable

• Fully keyboard-accessible; no traps.
• Visible focus indicator on all interactive elements.
• Skip link to main content.
• No forced orientation unless essential.
• Timers adjustable/extendable where applicable.
• Hover/focus content dismissible, persistent, and hoverable.
• Gestures have simple alternatives; accidental taps can be canceled.

Understandable

• Clear labels; descriptive link text.
• Form errors identified, explained, and suggestions provided.
• Consistent navigation and component behavior.
• Autocomplete used for common input purposes.
• Status messages are announced programmatically.

Robust

• Valid, semantic HTML before ARIA.
• Proper roles, names, states; dynamic updates announced where needed.
• Test with real assistive technologies and across multiple browsers.

Practical code patterns you can copy

Visible and high-contrast focus styles:

button, a, input, textarea, [role="button"] {
  outline: 3px solid transparent;
  outline-offset: 2px;
}
button:focus-visible,
a:focus-visible,
input:focus-visible,
textarea:focus-visible,
[role="button"]:focus-visible {
  outline-color: #0b5fff; /* Ensure 3:1 contrast with adjacent colors */
  box-shadow: 0 0 0 3px rgba(11,95,255,0.25);
}

Reduce motion for users who prefer it:

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }
}

Accessible name matches visible label (Label in Name):

<!-- Visible text “Search” appears in accessible name -->
<label for="site-search">Search</label>
<input id="site-search" type="search" aria-label="Search">

Avoid “click here” links:

<!-- Better: link conveys purpose -->
<a href="/pricing">Compare pricing plans</a>

From compliance to excellence: making it sustainable

WCAG 2.1 AA compliance is a strong, achievable standard—and it’s not the ceiling. As you mature:

• Extend to WCAG 2.1 AAA where practical (e.g., higher contrast, sign language for key videos, target size).
• Start aligning with WCAG 2.2 updates (e.g., focus appearance, dragging movements, target size minimum).
• Invest in inclusive research and iterative improvements.
• Track outcomes: task completion rates, form error reductions, support tickets about accessibility, and satisfaction scores from users with disabilities.

Accessibility isn’t a one-time project; it’s a product quality discipline. When teams adopt accessible patterns, test consistently, and listen to user feedback, accessibility becomes a natural byproduct of good design and engineering.

Your next steps

1. Set a target: WCAG 2.1 AA for your site or product.
2. Audit your current experience: run automated scans, do a keyboard walkthrough, check contrast, and test forms.
3. Prioritize fixes: focus on navigation, keyboard access, forms, color contrast, and media captions.
4. Standardize: update your design system with accessible components and tokens.
5. Train and align: ensure designers, writers, developers, and QA share the same patterns and checklists.
6. Monitor and iterate: schedule audits, track metrics, and react to user feedback quickly.

Mastering WCAG 2.1 isn’t just about compliance—it’s about delivering a digital experience that welcomes everyone, regardless of ability, device, or context. When you build inclusively, you build better.