Web Design Lab Guide

Can everyone use your website? Not just people like you. Everyone.

Approximately 15-20% of the global population has some form of disability. That’s over one billion people who might struggle with or be completely unable to use inaccessible websites. This isn’t a small niche. It’s a significant portion of your potential audience.

Web accessibility isn’t just ethical. It’s often legally required. The Americans with Disabilities Act (ADA), European Accessibility Act, and similar laws worldwide mandate accessible digital experiences. Companies face lawsuits and fines for inaccessible websites.

But beyond legal compliance, accessibility makes your site better for everyone. Captions help people in noisy environments. Keyboard navigation helps power users. Clear content structure helps people who are tired or distracted. Accessibility improvements benefit all users.

This guide walks through WCAG 2.2 (Web Content Accessibility Guidelines) requirements with practical implementation steps. You’ll learn what to do, why it matters, and how to test it.

TL;DR: Accessibility Essentials

• WCAG 2.2 has three levels – A (minimum), AA (target), AAA (enhanced)
• Four core principles (POUR) – Perceivable, Operable, Understandable, Robust
• Keyboard navigation must work – Every function accessible without mouse
• Color contrast matters – 4.5:1 for text, 3:1 for large text and UI
• Alt text for images – Describe content, not just “image of”
• Semantic HTML is foundation – Use proper elements, not just divs
• Forms need labels – Every input associated with descriptive label
• Focus states must be visible – Users need to see where they are
• Test with assistive tech – Screen readers, keyboard-only, voice control

Understanding WCAG 2.2

The Web Content Accessibility Guidelines (WCAG) are international standards for web accessibility, maintained by the W3C (World Wide Web Consortium).

The Three Conformance Levels

Level A (Minimum): Basic accessibility features. If you don’t meet Level A, some users cannot access your content at all. This is the absolute minimum.

Level AA (Target): Recommended target for most websites. Addresses major barriers for people with disabilities. This is what most laws reference.

Level AAA (Enhanced): Highest level of accessibility. Not all content can meet AAA. It’s a goal for specific content types but not a realistic requirement for entire sites.

Most organizations aim for Level AA compliance. It balances accessibility with practicality.

What’s New in WCAG 2.2

WCAG 2.2 (published October 2023) adds new success criteria focused on mobile accessibility and cognitive disabilities:

• 2.4.11 Focus Not Obscured (Minimum) – Focused elements must be at least partially visible
• 2.4.12 Focus Not Obscured (Enhanced) – Focused elements must be fully visible
• 2.4.13 Focus Appearance – Focus indicators must be clearly visible
• 2.5.7 Dragging Movements – Functionality requiring dragging must have alternatives
• 2.5.8 Target Size (Minimum) – Touch targets must be at least 24×24 CSS pixels
• 3.2.6 Consistent Help – Help mechanisms appear in consistent locations
• 3.3.7 Redundant Entry – Don’t ask users to re-enter information
• 3.3.8 Accessible Authentication (Minimum) – Cognitive function tests not required for authentication
• 3.3.9 Accessible Authentication (Enhanced) – Object recognition and personal content not required

These additions recognize mobile-first usage and cognitive accessibility needs.

The POUR Principles

WCAG organizes requirements around four principles. Content must be:

Perceivable: Users can perceive the information being presented. This means providing alternatives for non-text content, ensuring sufficient contrast, and making content adaptable.

Operable: Users can operate the interface. This means keyboard accessibility, adequate time to read and use content, avoiding seizure triggers, and providing navigation aids.

Understandable: Users can understand the information and operation of the interface. This means readable text, predictable behavior, and input assistance.

Robust: Content can be interpreted by a wide variety of user agents, including assistive technologies. This means using valid, semantic code that works with current and future tools.

Remember POUR. Every accessibility requirement falls under one of these principles.

Keyboard Accessibility

Many users cannot use a mouse. They navigate with keyboard, switch devices, or voice control. If your site doesn’t work with keyboard alone, it’s inaccessible to these users.

Every Interactive Element Must Be Keyboard Accessible

Users must be able to:

• Navigate to every interactive element
• Activate buttons, links, and controls
• Fill out and submit forms
• Close dialogs and modals
• Access all functionality

Test this by unplugging your mouse and trying to use your site with only keyboard:

• Tab moves focus forward
• Shift + Tab moves focus backward
• Enter activates buttons and links
• Space activates buttons and checkboxes
• Arrow keys navigate within components (like menus or radio groups)
• Escape closes dialogs

If you can’t complete tasks with keyboard alone, you have accessibility problems.

Focus Indicators Must Be Visible

Users need to see which element currently has focus. The default browser focus outline works, but many designers hide it with outline: none for aesthetic reasons.

Never remove focus indicators without providing an alternative:

/* DON'T DO THIS */
button:focus {
  outline: none; /* Makes focus invisible */
}

/* DO THIS INSTEAD */
button:focus {
  outline: 2px solid blue;
  outline-offset: 2px;
}

/* Or use a visible box-shadow */
button:focus {
  outline: none;
  box-shadow: 0 0 0 3px rgba(0, 100, 255, 0.5);
}

WCAG 2.2 requires focus indicators to be clearly visible with adequate contrast and size.

Focus Order Must Be Logical

Focus should move through the page in a logical order, typically top to bottom and left to right (in left-to-right languages).

Visual position should match DOM order. If elements appear in one order visually but exist in different order in HTML, keyboard navigation becomes confusing.

Avoid using CSS to drastically reorder content. Use flexbox order or grid placement cautiously.

No Keyboard Traps

Users must be able to move focus away from any element using only keyboard. Modal dialogs are common offenders.

Keyboard trap example (bad):

// User tabs into modal but can't tab out
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Tab') {
    e.preventDefault(); // Traps focus forever
  }
});

Proper focus management (good):

// Trap focus within modal, but allow Escape to close
const focusableElements = modal.querySelectorAll('button, a, input');
const firstElement = focusableElements[0];
const lastElement = focusableElements[focusableElements.length - 1];

modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
  }
  
  if (e.key === 'Tab') {
    if (e.shiftKey && document.activeElement === firstElement) {
      lastElement.focus();
      e.preventDefault();
    } else if (!e.shiftKey && document.activeElement === lastElement) {
      firstElement.focus();
      e.preventDefault();
    }
  }
});

This traps focus within the modal (which is appropriate) but allows Escape to exit.

Skip Links for Navigation

Long navigation menus frustrate keyboard users who must tab through every link to reach main content. Provide skip links:

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

<nav>
  <!-- 20+ navigation links -->
</nav>

<main id="main-content">
  <!-- Main content here -->
</main>

Style skip links to be visually hidden but appear on focus:

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

When users tab to the skip link and press Enter, they jump past navigation directly to content.

Color and Contrast

Vision varies widely. Some users have low vision, color blindness, or view screens in bright sunlight. Sufficient contrast ensures text remains readable.

WCAG Contrast Requirements

Normal text (under 24px or under 19px bold): Minimum 4.5:1 contrast ratio with background

Large text (24px+ or 19px+ bold): Minimum 3:1 contrast ratio

UI components and graphics: Minimum 3:1 contrast for interactive elements and meaningful graphics

These are Level AA requirements. Level AAA requires 7:1 for normal text and 4.5:1 for large text.

Testing Contrast

Use tools to verify contrast ratios:

Browser extensions:

• WAVE (Web Accessibility Evaluation Tool)
• axe DevTools
• Lighthouse (built into Chrome DevTools)

Online checkers:

• WebAIM Contrast Checker
• Contrast Ratio by Lea Verou

Design tool plugins:

• Stark for Figma, Sketch, Adobe XD
• Contrast in Figma

Check every text color against every background color it appears on. Don’t forget hover states, selected states, and disabled states.

Color Cannot Be the Only Indicator

Never use color alone to convey information. Always pair color with another indicator:

Form validation:

<!-- BAD: Color only -->
<input class="error"> <!-- Just red border -->

<!-- GOOD: Color + icon + text -->
<input class="error" aria-invalid="true">
<span class="error-message">
  <svg aria-hidden="true"><use href="#error-icon"/></svg>
  Email format is invalid
</span>

Required fields:

<!-- BAD: Red asterisk only -->
<label>Name <span style="color: red;">*</span></label>

<!-- GOOD: Text + visual indicator -->
<label>Name <span aria-label="required">(required)</span></label>

Charts and graphs: Use patterns, labels, or textures in addition to color. Don’t rely solely on color to distinguish data series.

Simulating Color Blindness

Test your design with color blindness simulation:

Browser DevTools:

• Chrome: DevTools → Rendering → Emulate vision deficiencies
• Firefox: Accessibility Inspector

Tools:

• Color Oracle (free desktop app)
• Coblis (online simulator)

Common types to test:

• Deuteranopia (red-green, most common)
• Protanopia (red-green variant)
• Tritanopia (blue-yellow)
• Achromatopsia (complete color blindness)

If important distinctions disappear under simulation, your design isn’t accessible.

Semantic HTML and Structure

Proper HTML structure is the foundation of accessibility. Assistive technologies rely on semantic elements to understand page structure.

Use Proper Heading Hierarchy

Headings (h1-h6) create an outline screen reader users navigate. Never skip heading levels.

<!-- GOOD: Logical hierarchy -->
<h1>Page Title</h1>
  <h2>Main Section</h2>
    <h3>Subsection</h3>
    <h3>Another Subsection</h3>
  <h2>Another Main Section</h2>

<!-- BAD: Skipped levels -->
<h1>Page Title</h1>
  <h4>Main Section</h4> <!-- Skipped h2 and h3 -->

Use only one h1 per page. It should be the main page title or primary content heading.

Don’t choose heading levels based on visual appearance. Use CSS to control appearance while maintaining logical structure.

Landmark Regions

Landmark elements help screen reader users understand page structure and navigate efficiently:

<header>
  <nav aria-label="Main navigation">
    <!-- Primary navigation -->
  </nav>
</header>

<main>
  <article>
    <h1>Article Title</h1>
    <!-- Article content -->
  </article>
  
  <aside>
    <!-- Related content -->
  </aside>
</main>

<footer>
  <nav aria-label="Footer navigation">
    <!-- Secondary navigation -->
  </nav>
</footer>

Landmark elements:

• <header> – Banner landmark (site header)
• <nav> – Navigation landmark
• <main> – Main content landmark (only one per page)
• <aside> – Complementary landmark
• <footer> – Contentinfo landmark (site footer)
• <section> – Generic section (use with heading)
• <article> – Self-contained content

Screen reader users can jump between landmarks, skipping irrelevant sections.

Lists for Related Items

Use proper list elements for lists:

<!-- Navigation -->
<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

<!-- Instructions -->
<ol>
  <li>First, do this</li>
  <li>Then, do that</li>
  <li>Finally, complete the process</li>
</ol>

<!-- Definition list -->
<dl>
  <dt>Term</dt>
  <dd>Definition of the term</dd>
</dl>

Don’t create visual lists with <br> tags or <div> elements. Screen readers announce list structure, which helps users understand relationships.

Tables for Tabular Data

Use tables only for tabular data, never for layout. Provide proper table structure:

<table>
  <caption>Monthly Sales Data</caption>
  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Sales</th>
      <th scope="col">Change</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">January</th>
      <td>$50,000</td>
      <td>+5%</td>
    </tr>
    <!-- More rows -->
  </tbody>
</table>

Key elements:

• <caption> describes the table
• <thead>, <tbody>, <tfoot> group rows
• <th> for header cells with scope attribute
• scope="col" for column headers
• scope="row" for row headers

This structure lets screen readers announce “Row 1, January, $50,000, +5%” so users understand relationships.

Buttons vs Links

Use semantic elements appropriately:

Links navigate to different pages or locations:

<a href="/about">About Us</a>

Buttons perform actions on the current page:

<button type="button">Open Menu</button>
<button type="submit">Submit Form</button>

Don’t make divs clickable. Use actual buttons and links:

<!-- BAD -->
<div onclick="doSomething()">Click me</div>

<!-- GOOD -->
<button onclick="doSomething()">Click me</button>

Proper elements provide built-in keyboard support, focus management, and screen reader announcements.

Alternative Text for Images

Images must have text alternatives for screen reader users. The alt attribute provides this.

When to Provide Alt Text

Informative images convey content or information:

<img src="chart.png" alt="Bar chart showing 30% increase in sales from Q1 to Q2">

Describe what information the image conveys, not just what it depicts.

Functional images are clickable (buttons, links):

<a href="/search">
  <img src="search-icon.svg" alt="Search">
</a>

Describe the function, not the image. “Search” not “magnifying glass icon.”

Decorative images add visual interest but convey no information:

<img src="decorative-border.svg" alt="">

Empty alt attribute tells screen readers to skip the image. Don’t omit the alt attribute entirely.

Complex images like infographics or diagrams:

<img src="infographic.png" alt="Annual report infographic">
<details>
  <summary>Detailed description</summary>
  <p>Full text description of all information in the infographic...</p>
</details>

Provide brief alt text plus link to or inline detailed description.

Writing Good Alt Text

Be specific and concise:

• Good: “Golden retriever puppy playing in grass”
• Bad: “Dog” or “Image of a dog”

Context matters:

• On pet adoption site: “Max, 6-month-old golden retriever, available for adoption”
• In blog about photography: “Golden retriever puppy photographed with shallow depth of field”

Avoid redundancy:

• Don’t start with “image of” or “picture of”
• Don’t repeat adjacent text
• Don’t include file names

Keep it under 150 characters when possible. Screen readers may truncate longer descriptions.

CSS Background Images

Background images added via CSS aren’t accessible to screen readers. They’re purely decorative by definition.

If a background image conveys information, it should be an <img> element instead. If it’s truly decorative, it belongs in CSS.

Icon Fonts and SVG Icons

Icon fonts without text need accessible alternatives:

<!-- Icon with visible text -->
<button>
  <svg aria-hidden="true"><use href="#icon-search"/></svg>
  Search
</button>

<!-- Icon without visible text -->
<button aria-label="Search">
  <svg aria-hidden="true"><use href="#icon-search"/></svg>
</button>

The aria-hidden="true" attribute tells screen readers to ignore the icon. The visible text or aria-label provides the accessible name.

Form Accessibility

Forms are critical interactions that must work for everyone. Accessible forms are also easier for all users.

Every Input Needs a Label

Associate labels with inputs using the for and id attributes:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

The connection lets users click the label to focus the input and tells screen readers what the input is for.

Never use placeholder alone as a label:

<!-- BAD -->
<input type="email" placeholder="Email address">

<!-- GOOD -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="[email protected]">

Placeholders disappear on focus and have insufficient contrast. They’re hints, not labels.

Group Related Inputs

Use <fieldset> and <legend> for groups:

<fieldset>
  <legend>Shipping address</legend>
  
  <label for="street">Street</label>
  <input type="text" id="street">
  
  <label for="city">City</label>
  <input type="text" id="city">
  
  <label for="zip">ZIP code</label>
  <input type="text" id="zip">
</fieldset>

Screen readers announce “Shipping address, Street” when users focus the street input, providing context.

For radio buttons and checkboxes, fieldset is essential:

<fieldset>
  <legend>Choose a delivery method</legend>
  
  <input type="radio" id="standard" name="delivery" value="standard">
  <label for="standard">Standard (5-7 days)</label>
  
  <input type="radio" id="express" name="delivery" value="express">
  <label for="express">Express (2-3 days)</label>
</fieldset>

Required Fields and Validation

Mark required fields explicitly:

<label for="name">
  Name <span aria-label="required">(required)</span>
</label>
<input type="text" id="name" required aria-required="true">

The visual indicator and ARIA attribute both communicate the requirement.

For validation errors, provide clear, helpful messages:

<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<span id="email-error" class="error">
  Please enter a valid email address (e.g., [email protected])
</span>

aria-invalid tells screen readers the input has an error. aria-describedby associates the error message with the input.

Move focus to the first error after form submission and announce the error to screen reader users.

Helpful Error Messages

Generic errors frustrate everyone:

<!-- BAD -->
<span>Invalid input</span>

<!-- GOOD -->
<span>Password must be at least 8 characters and include one number</span>

Explain what’s wrong and how to fix it. Be specific and constructive.

Accessible Custom Controls

If you must create custom selects, date pickers, or other controls, follow ARIA authoring practices. Better yet, use native HTML controls when possible.

Custom controls require:

• Proper ARIA roles and attributes
• Full keyboard support
• Focus management
• Screen reader announcements

Native controls provide all of this automatically.

ARIA (Accessible Rich Internet Applications)

ARIA attributes enhance accessibility when HTML semantics aren’t enough. But ARIA is a supplement, not a replacement for semantic HTML.

The First Rule of ARIA

“If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding ARIA, then do so.”

Use <button> instead of <div role="button">. The native element works better.

Common ARIA Attributes

aria-label: Provides a label when visual label doesn’t exist

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

aria-labelledby: Points to another element containing the label

<h2 id="dialog-title">Confirm deletion</h2>
<div role="dialog" aria-labelledby="dialog-title">
  <!-- Dialog content -->
</div>

aria-describedby: Points to additional description

<input type="password" aria-describedby="password-requirements">
<div id="password-requirements">
  Must be 8+ characters with one number
</div>

aria-hidden: Hides decorative elements from screen readers

<svg aria-hidden="true"><!-- Icon --></svg>

aria-live: Announces dynamic content changes

<div aria-live="polite" aria-atomic="true">
  <!-- Status messages appear here and are announced -->
</div>

ARIA Roles

Roles define what an element is or does:

<div role="navigation"><!-- Navigation --></div>
<div role="main"><!-- Main content --></div>
<div role="dialog"><!-- Modal dialog --></div>
<div role="alert"><!-- Important message --></div>

But native elements already have roles. Use <nav> instead of <div role="navigation">.

ARIA States and Properties

aria-expanded: For expandable elements

<button aria-expanded="false" aria-controls="menu">
  Menu
</button>
<div id="menu" hidden>
  <!-- Menu items -->
</div>

When menu opens, change aria-expanded to “true” and remove hidden.

aria-current: Indicates current item in a set

<nav>
  <a href="/">Home</a>
  <a href="/about" aria-current="page">About</a>
  <a href="/contact">Contact</a>
</nav>

aria-disabled: For disabled interactive elements

<button aria-disabled="true">Submit</button>

Prefer disabled attribute on native elements when possible.

Testing for Accessibility

Automated tools catch some issues, but manual testing is essential. Real users find problems tools miss.

Automated Testing Tools

Browser extensions:

• axe DevTools: Comprehensive, catches many issues
• WAVE: Visual feedback, good for learning
• Lighthouse: Built into Chrome, tests accessibility and performance

Command-line tools:

• Pa11y: Automated testing in CI/CD pipelines
• axe-core: Library for custom testing

Run automated tests regularly. They catch obvious problems like missing alt text or insufficient contrast.

But automated tools catch only 30-40% of accessibility issues. They can’t evaluate whether alt text is meaningful, whether heading structure makes sense, or whether custom components work properly.

Manual Testing Checklist

Keyboard navigation:

• Unplug your mouse
• Tab through every interactive element
• Verify focus indicators are visible
• Try common keyboard shortcuts
• Ensure no keyboard traps exist

Screen reader testing:

• NVDA (Windows): Free, most commonly used
• JAWS (Windows): Commercial, widely used in enterprise
• VoiceOver (Mac/iOS): Built-in, commonly used on Apple devices
• TalkBack (Android): Built-in Android screen reader

Navigate your site with screen reader enabled. Does it make sense? Can you complete tasks? Do images, form fields, and custom components have appropriate labels?

Zoom and text scaling:

• Zoom browser to 200%
• Does layout break?
• Is all content still accessible?
• Do interactive elements remain usable?

Color and contrast:

• Run contrast checker on all text
• Test with color blindness simulation
• Verify color isn’t the only indicator

Mobile accessibility:

• Touch targets at least 24x24px (WCAG 2.2)
• Content reflows appropriately
• All functionality available on touch devices

User Testing

Nothing replaces testing with actual users with disabilities. Recruit testers who:

• Use screen readers daily
• Navigate with keyboard only
• Have low vision and use magnification
• Have motor impairments and use assistive devices
• Have cognitive disabilities

Their feedback reveals issues automated tools and manual testing miss.

Accessibility Audit Services

For critical sites or legal compliance, consider professional audits:

• Identify and prioritize issues
• Provide detailed remediation guidance
• Offer certification for compliance

Professional auditors combine automated testing, manual testing, and expertise in assistive technologies.

Common Accessibility Mistakes

Even well-intentioned developers make these errors. Avoid them.

Using Divs for Everything

<!-- BAD -->
<div onclick="submit()">Submit</div>

<!-- GOOD -->
<button type="submit">Submit</button>

Semantic HTML provides accessibility automatically. Divs provide nothing.

Low Contrast Text

Light gray on white backgrounds might look sophisticated, but users can’t read it. Always verify contrast ratios.

Removing Focus Indicators

/* NEVER DO THIS without providing alternative */
*:focus {
  outline: none;
}

Keyboard users need focus indicators. Style them if you must, but never remove them entirely.

Placeholder as Label

<!-- BAD -->
<input type="email" placeholder="Email">

<!-- GOOD -->
<label for="email">Email</label>
<input type="email" id="email">

Placeholders aren’t accessible substitutes for labels.

Inaccessible Modals

Modals must trap focus, allow keyboard navigation, close on Escape, and return focus to the trigger element when closed.

Many custom modal implementations fail these requirements.

Auto-Playing Media

Videos that auto-play with sound are problematic for screen reader users (they can’t hear the screen reader) and photosensitive users (unexpected motion can trigger seizures).

Provide pause/stop controls. Never auto-play with audio enabled.

PDF Documents

PDFs are often inaccessible. If you must use PDFs:

• Create them from accessible documents
• Tag them properly
• Provide HTML alternative
• Test with screen readers

Better yet, use HTML for content and reserve PDFs for printable documents only.

Ignoring Mobile Accessibility

Touch targets, spacing, and readability matter. Mobile users include people with disabilities using adaptive technology.

Legal Requirements and Compliance

Accessibility isn’t just best practice. It’s often legally required.

United States: ADA and Section 508

The Americans with Disabilities Act (ADA) applies to websites, despite being written before the web existed. Courts have ruled that websites are “places of public accommodation.”

Section 508 requires federal agencies and their contractors to make electronic content accessible.

Both typically reference WCAG 2.0 Level AA, though some organizations are moving to WCAG 2.1 or 2.2.

European Union: European Accessibility Act

The European Accessibility Act requires accessibility for many digital products and services. Member states must implement it by 2025.

Most EU countries reference EN 301 549, which incorporates WCAG 2.1 Level AA.

Other Jurisdictions

Many countries have accessibility laws:

• Canada: Accessible Canada Act
• UK: Equality Act 2010
• Australia: Disability Discrimination Act 1992
• Japan: JIS X 8341-3

Research requirements for your specific jurisdiction. When in doubt, WCAG 2.1 Level AA is widely recognized.

Litigation Risks

Web accessibility lawsuits are increasing, particularly in the US. Companies face:

• Legal fees (even if they win)
• Settlement costs
• Court-ordered remediation
• Reputation damage

Proactive accessibility is cheaper and less risky than reactive fixes after litigation.

Conclusion

Accessibility ensures everyone can use your website, regardless of ability. It’s ethical, often legal, and improves the experience for all users.

Key takeaways:

• WCAG 2.2 Level AA is the target standard for most websites
• Keyboard accessibility is fundamental – everything must work without a mouse
• Color contrast must meet 4.5:1 for normal text, 3:1 for large text
• Semantic HTML provides foundational accessibility
• Every image needs appropriate alt text
• Forms require proper labels, grouping, and error handling
• ARIA supplements HTML but never replaces it
• Automated tools catch some issues; manual testing catches more
• Testing with real users with disabilities finds the most issues
• Accessibility is legally required in many jurisdictions

The action you should take today: Run an automated test (Lighthouse, WAVE, or axe) on your site. Fix the easiest issues first. Then test keyboard navigation. Can you use your site without a mouse?

Accessibility is a journey, not a destination. Start with the biggest issues and progressively improve. Every fix helps real users have better experiences.

Ready to ensure your designs work for mobile users? Check out our guide on Should You Design Mobile-First or Desktop-First? (Pros & Cons), where we explore the strategic and accessibility benefits of mobile-first design approaches.

Quick Reference: Accessibility Checklist

Use this for every project:

1. All content keyboard accessible – Tab through every function
2. Focus indicators visible – Never remove without replacement
3. Sufficient color contrast – 4.5:1 minimum for text
4. Semantic HTML used – Proper headings, landmarks, buttons, links
5. Images have alt text – Appropriate for context
6. Forms have labels – Associated with for/id attributes
7. No keyboard traps – Users can navigate away from everything
8. Error messages clear – Specific and helpful guidance
9. Valid HTML – Check with W3C validator
10. Screen reader tested – Actually use NVDA, VoiceOver, or JAWS
11. Zoom to 200% – Layout remains usable
12. Touch targets 24x24px minimum – WCAG 2.2 requirement

Frequently Asked Questions

What is WCAG and why does it matter? WCAG (Web Content Accessibility Guidelines) are international standards for web accessibility. They define how to make content accessible to people with disabilities. Most accessibility laws reference WCAG standards.

What is the difference between WCAG A, AA, and AAA? Level A is minimum accessibility. Level AA is the recommended target for most sites. Level AAA is enhanced accessibility that not all content can achieve. Most organizations aim for AA.

Do I need to support screen readers? Yes. Screen readers are essential assistive technology for blind users. If your site doesn’t work with screen readers, it’s inaccessible to this population.

What color contrast ratio do I need? WCAG Level AA requires 4.5:1 for normal text and 3:1 for large text (24px+ or 19px+ bold). Level AAA requires 7:1 for normal text.

Can automated tools test accessibility completely? No. Automated tools catch only 30-40% of issues. Manual testing with keyboard, screen readers, and real users is essential.

Is my website legally required to be accessible? It depends on your location and type of site. In the US, ADA applies broadly. EU has the European Accessibility Act. Many countries have laws requiring accessibility. Consult legal counsel for specific requirements.

How do I write good alt text? Be specific and concise. Describe what information the image conveys, not just what it depicts. Consider context. Keep it under 150 characters when possible.

References & Further Reading

• Web Content Accessibility Guidelines (WCAG) 2.2 – W3C
• ARIA Authoring Practices Guide (APG) – W3C
• “Inclusive Design Patterns” – Pickering, H.
• “Accessibility for Everyone” – Horton, S.
• WebAIM (Web Accessibility In Mind)
• A11y Project (Community-driven accessibility resources)
• “Don’t Make Me Think” – Krug, S.
• Deque University (WCAG training and resources)