How to Design Accessible Websites: WCAG 2.2 Guide for 2027

Quick answer: To design accessible websites, follow WCAG 2.2 guidelines: provide text alternatives for images (alt text), ensure keyboard navigation, maintain sufficient color contrast (4.5:1 for text), use semantic HTML, provide captions for videos, ensure focus indicators are visible, and test with screen readers. WCAG 2.2 adds new criteria: focus not obscured, dragging movements, target size (minimum 24×24px), consistent help, redundant entry, and accessible authentication. Accessibility is both a legal requirement and good UX.[1][3][4]

Web accessibility ensures that people with disabilities can use your website. In 2027, with increasing legal requirements (ADA, European Accessibility Act) and AI search engines evaluating accessibility, it's both a compliance necessity and a competitive advantage.

WCAG 2.2 overview

WCAG (Web Content Accessibility Guidelines) 2.2 has 4 principles (POUR):

1. Perceivable: Content must be perceivable by all users
2. Operable: Interface must be operable by all users
3. Understandable: Content must be understandable
4. Robust: Content must work with assistive technologies

Conformance levels

• Level A: Minimum accessibility (must have)
• Level AA: Standard accessibility (should have) — most legal requirements target this
• Level AAA: Enhanced accessibility (nice to have)

Key WCAG 2.2 criteria

1. Text alternatives (1.1.1)

All non-text content needs text alternatives:

<img src="chart.webp" alt="Bar chart showing 80% reduction in image size with WebP format">

Alt text best practices:

• Describe the content and function
• Be concise (under 125 characters)
• Don't start with "Image of" or "Picture of"
• For decorative images: use alt="" (empty, not missing)
• For complex images (charts, diagrams): provide long description[3]

2. Color contrast (1.4.3)

Minimum contrast ratios:

• Normal text (under 18px): 4.5:1
• Large text (18px+ or 14px+ bold): 3:1
• UI components and graphics: 3:1

Tools: WebAIM Contrast Checker, Chrome DevTools (contrast ratio in color picker).[3]

3. Keyboard navigation (2.1.1)

All functionality must be accessible via keyboard:

• Tab to navigate
• Enter/Space to activate
• Arrow keys for menus/sliders
• Escape to close modals

Test: Unplug your mouse and navigate the site using only the keyboard.[3]

4. Focus indicators (2.4.7, 2.4.11)

Visible focus indicators for keyboard users:

/* Default focus (often removed — don't do this) */
*:focus { outline: none; } /* BAD */

/* Good focus indicator */
*:focus-visible {
  outline: 2px solid #5cffb0;
  outline-offset: 2px;
}

WCAG 2.2 adds: focus must not be completely obscured by other content (2.4.11).[3]

5. Target size (2.5.8) — NEW in 2.2

Interactive targets must be at least 24×24 CSS pixels (or have sufficient spacing). This prevents accidental clicks on touch devices.[3]

6. Consistent help (3.2.6) — NEW in 2.2

Help mechanisms (contact info, chat, FAQ) must be in the same relative order across pages.[3]

7. Redundant entry (3.2.7) — NEW in 2.2

Don't ask users to re-enter information they already provided. Auto-populate when possible.[3]

8. Accessible authentication (3.3.8) — NEW in 2.2

Login processes must not rely solely on cognitive tests (like CAPTCHA). Provide alternatives (email link, biometric, passkey).[3]

9. Dragging movements (2.5.7) — NEW in 2.2

Any functionality that uses dragging must have a single-pointer alternative (click/tap).[3]

Semantic HTML

Use proper HTML elements instead of styled divs:

<!-- Bad: divs with ARIA roles -->
<div role="button" tabindex="0" onclick="submit()">Submit</div>

<!-- Good: semantic elements -->
<button type="submit">Submit</button>

<!-- Bad: div navigation -->
<div class="nav">
  <div class="nav-item">Home</div>
</div>

<!-- Good: semantic navigation -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
  </ul>
</nav>

Semantic elements: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <a>, <form>, <label>, <table>, <figure>.[3]

ARIA (Accessible Rich Internet Applications)

Use ARIA when semantic HTML isn't sufficient:

<!-- ARIA labels -->
<button aria-label="Close dialog">×</button>

<!-- ARIA live regions (for dynamic content) -->
<div aria-live="polite" aria-atomic="true">
  <!-- Screen reader announces changes -->
</div>

<!-- ARIA expanded -->
<button aria-expanded="false" aria-controls="menu">Menu</button>
<ul id="menu" hidden>...</ul>

Rule: Use semantic HTML first. Add ARIA only when HTML isn't enough. Don't use ARIA to fix bad HTML.[3]

Forms accessibility

<form>
  <label for="email">Email address</label>
  <input type="email" id="email" name="email" required
         aria-describedby="email-hint">
  <span id="email-hint">We'll never share your email.</span>
  
  <!-- Error message -->
  <span role="alert" id="email-error">Please enter a valid email.</span>
</form>

Best practices:

• Always use <label> elements (not placeholder text as labels)
• Group related fields with <fieldset> and <legend>
• Provide clear error messages
• Use appropriate input types (email, tel, number)
• Don't rely on color alone for validation (add icons/text)[3]

Testing accessibility

Automated testing

Manual testing

1. Keyboard navigation: Tab through entire site
2. Screen reader: Test with NVDA (Windows), VoiceOver (Mac), TalkBack (Android)
3. Color contrast: Check all text against backgrounds
4. Zoom: Test at 200% zoom
5. Reduced motion: Test with prefers-reduced-motion enabled[3][4]

User testing

The most effective testing: include users with disabilities in your testing process. Automated tools can't catch all issues.[3]

Legal requirements

United States (ADA)

• ADA Title III applies to websites as "places of public accommodation"
• WCAG 2.1 AA is the de facto standard
• Lawsuits increasing: 4,000+ ADA website lawsuits in 2026[3]

European Union (European Accessibility Act)

• Applies to all digital products and services
• WCAG 2.1 AA required by June 2025
• Applies to e-commerce, banking, transport, and more[3]

Other jurisdictions

• UK: Equality Act 2010
• Canada: AODA (Ontario)
• Australia: DDA
• Most countries have accessibility legislation[3]

Frequently Asked Questions (FAQ)

What is WCAG?

WCAG (Web Content Accessibility Guidelines) is a set of guidelines for making web content accessible to people with disabilities. Published by W3C, current version is 2.2 (2023). Most legal requirements target Level AA.[1][3]

Is web accessibility legally required?

In many jurisdictions, yes. ADA (US), European Accessibility Act (EU), and similar laws in other countries require websites to be accessible. Non-compliance can result in lawsuits and fines.[3]

What is the difference between WCAG 2.1 and 2.2?

WCAG 2.2 adds 9 new success criteria: focus not obscured, dragging movements, target size (minimum 24×24px), consistent help, redundant entry, accessible authentication, and more. All 2.1 criteria are included in 2.2.[3]

Can automated tools catch all accessibility issues?

No. Automated tools catch 30-40% of issues. Manual testing (keyboard navigation, screen reader, color contrast) and user testing are essential for comprehensive accessibility.[3][4]

What is ARIA?

ARIA (Accessible Rich Internet Applications) is a set of attributes that enhance HTML semantics for assistive technologies. Use semantic HTML first; add ARIA only when HTML isn't sufficient.[3]

How do I make my website screen reader friendly?

Use semantic HTML, provide alt text for images, use ARIA labels for interactive elements, ensure logical heading structure, and test with actual screen readers (NVDA, VoiceOver).[3]

What is color contrast and why does it matter?

Color contrast is the difference in luminance between text and background. Low contrast makes text hard to read for users with visual impairments. WCAG requires 4.5:1 for normal text, 3:1 for large text.[3]

How much does accessibility cost?

For new projects: 5-10% additional development time if accessibility is built in from the start. For retrofitting existing sites: 20-40% of development time. The cost of non-compliance (lawsuits, fines) is much higher.[3][4]

Related reading on MintSaaS

• Color Contrast: How to Meet Accessibility Standards
• How to Improve Website Speed: Complete Performance Guide
• How to Optimize Images for SEO: Complete Guide

Sources

[1] W3C — WCAG 2.2: https://www.w3.org/TR/WCAG22/

[2] WebAIM — Contrast Checker: https://webaim.org/resources/contrastchecker/

[3] MintSaaS Image Compressor: https://www.mintsaas.net/products/image-compressor

[4] Web.dev — Core Web Vitals: https://web.dev/vitals/

[5] MintSaaS PDF Compressor: https://www.mintsaas.net/products/pdf-compressor

Free tools on MintSaaS

Try our free tools to put this guide into practice:

• Image Compressor
• PDF Compressor
• Image Converter
• MintSaaS Home
• MintSaaS Blog
• How to Compress Images