Website Accessibility Guide 2026: WCAG 2.1 AA Checklist, Alt Text, Keyboard Nav & ARIA

15 min read · Web Development · Last updated July 2026

Quick answer: WCAG 2.1 AA is the globally accepted accessibility standard. It requires that websites are Perceivable, Operable, Understandable, and Robust. The most impactful fixes are: alt text on all images, sufficient colour contrast (≥4.5:1), keyboard navigation support, and semantic HTML structure.

Introduction

Over 1.3 billion people worldwide live with some form of disability. That’s 16% of the global population — and a significant portion of your website’s potential audience. When websites are designed without accessibility in mind, these users are either excluded entirely or face friction that makes their experience significantly harder.

Beyond the ethical argument, accessibility has become a legal and business concern. In the United States, the number of ADA accessibility lawsuits targeting websites has grown consistently — reaching over 4,600 federal cases in a single year. The EU has the European Accessibility Act requiring WCAG 2.1 AA compliance for digital products by 2025. Australia has DDA obligations. In Nepal and across South Asia, digital accessibility standards are increasingly referenced in public sector procurement.

Accessible websites also perform better in SEO — semantic HTML, descriptive alt text, and logical heading structures are signals that search engines use to understand and rank content.

What you’ll learn:
– The WCAG 2.1 POUR framework in practical terms
– Specific implementation guidance for each criterion
– ARIA roles and when (and when not) to use them
– How to test accessibility with free tools
– The business case and legal context

Table of Contents

1. What WCAG 2.1 Is (and What It Requires)
2. Perceivable: Making Content Available to All Senses
3. Operable: Ensuring All Users Can Navigate
4. Understandable: Clear Language and Predictable Behaviour
5. Robust: Compatible with Assistive Technologies
6. Semantic HTML: The Foundation of Accessibility
7. ARIA Roles and When to Use Them
8. Testing Tools and Testing Process
9. Common Mistakes and How to Fix Them
10. Interactive Tools
11. FAQ

1. What WCAG 2.1 Is (and What It Requires)

The Web Content Accessibility Guidelines (WCAG) are published by the W3C (World Wide Web Consortium). They define an internationally recognised standard for accessible web content.

Conformance levels:
– Level A: Minimum accessibility — addresses the most severe barriers (not sufficient for compliance in most legal contexts)
– Level AA: The internationally recognised standard for legal compliance — this is what ADA lawsuits, EU accessibility law, and most government standards require
– Level AAA: Highest level — not required in full but individual AAA criteria are best practices

WCAG 2.1 (published 2018) added 17 new criteria on top of WCAG 2.0, primarily focused on mobile accessibility, cognitive accessibility, and low vision users. WCAG 2.2 (published 2023) added 9 more criteria. Most legal requirements still reference AA conformance with WCAG 2.1.

The POUR framework:
All WCAG criteria are organised under four principles:
– Perceivable: Information must be presentable to users in ways they can perceive
– Operable: UI components and navigation must be operable by all users
– Understandable: Information and UI operation must be understandable
– Robust: Content must be robust enough to be interpreted by assistive technologies

2. Perceivable

Alt Text for Images (SC 1.1.1)

Every non-decorative image must have a text alternative that serves the same purpose as the image.

Good alt text:

<!-- Informative image -->
<img src="bar-chart-q1-revenue.png" alt="Bar chart showing Q1 2026 revenue of $1.2M, up 34% year-over-year">

<!-- Functional image (linked) -->
<a href="/home"><img src="logo.png" alt="Ignited Nepal - Home"></a>

<!-- Decorative image (empty alt attribute, not missing) -->
<img src="decorative-divider.svg" alt="">

Poor alt text:

<img src="chart.png" alt="image">  <!-- Useless -->
<img src="chart.png">              <!-- Missing alt entirely — WCAG failure -->
<img src="chart.png" alt="bar-chart-q1-revenue.png"> <!-- Filename, not description -->

Alt text should describe the purpose and content of the image, not its visual appearance. A graph should describe the data it shows. A button image should describe its function.

Captions for Video (SC 1.2.2)

All pre-recorded video with audio must have captions. Live video must have captions at Level AA.

<video controls>
  <source src="product-demo.mp4" type="video/mp4">
  <track kind="captions" src="captions-en.vtt" srclang="en" label="English" default>
</video>

Auto-generated captions (YouTube, Zoom) are not sufficient for accessibility compliance — they typically have 80-90% accuracy, which leaves gaps that matter for users who rely on them.

Colour Contrast (SC 1.4.3 and 1.4.11)

Normal text (under 18pt or 14pt bold): minimum contrast ratio of 4.5:1 against background.
Large text (18pt+ or 14pt+ bold): minimum contrast ratio of 3:1.
UI components and graphics (SC 1.4.11): minimum 3:1 against adjacent colours.

/* Bad: Grey text on light grey background — likely fails 4.5:1 */
.subtitle { color: #999; background: #f5f5f5; }

/* Good: Dark text on light background */
.subtitle { color: #333; background: #f5f5f5; }
/* Contrast ratio: approximately 9.7:1 — passes */

Check contrast ratios with: WebAIM Contrast Checker, the browser DevTools accessibility panel, or Figma’s contrast plugin.

Don’t Use Colour Alone (SC 1.4.1)

Never convey information using colour as the only visual means. An error state that only turns a field red fails users with colour blindness.

⚠ Please enter a valid email address.

3. Operable

Keyboard Accessibility (SC 2.1.1)

All functionality must be accessible via keyboard. Tab navigates between focusable elements. Enter/Space activates buttons and links. Arrow keys navigate within components (menus, tabs, sliders).

Test this: disconnect your mouse and navigate your entire site using only the keyboard. If you get stuck, that’s a WCAG failure.

Common keyboard failures:
– Custom dropdowns built with <div> instead of <select> or a proper ARIA pattern
– Modal dialogs that don’t trap focus (user can tab behind the modal)
– Drag-and-drop interactions with no keyboard alternative
– JavaScript event listeners on mousedown only (keyboard fires keydown)

// Bad: only mouse users can activate this
element.addEventListener('mousedown', handleClick);

// Good: keyboard users (Enter/Space) can also activate
element.addEventListener('click', handleClick);
// Note: 'click' fires for keyboard Enter on buttons and links

Skip Navigation Link (SC 2.4.1)

A skip navigation link allows keyboard users to skip repeated content (header, nav) and jump directly to main content. Screen reader users and power keyboard users rely on this.

Focus Indicators (SC 2.4.7 and 2.4.11)

Keyboard users must be able to see which element is focused. The browser’s default outline is the minimum. WCAG 2.2 added 2.4.11 (AA) requiring focus indicators to be more visible: at least 2px solid outline with 3:1 contrast against adjacent colour.

/* Never do this */
:focus { outline: none; }

/* Good: prominent focus ring */
:focus-visible {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
  border-radius: 4px;
}

Using :focus-visible instead of :focus ensures the ring shows for keyboard navigation but not for mouse clicks — better UX without removing accessibility.

No Keyboard Traps (SC 2.1.2)

Keyboard focus must not get stuck in a component with no way to escape. The main exception is modal dialogs — focus should be trapped within the modal, but users must be able to close the modal with Escape and have focus returned to the trigger element.

Timing (SC 2.2.1)

If your site has time limits (session timeouts, countdown offers), users must be able to turn off, adjust, or extend the time limit. Exception: real-time events (live auctions) and essential security timeouts.

4. Understandable

Language of Page (SC 3.1.1)

Set the lang attribute on the <html> element. Screen readers use this to select the correct pronunciation rules.

Consistent Navigation (SC 3.2.3)

Navigation menus must appear in the same location and order across all pages. Users with cognitive disabilities rely on consistency to orient themselves.

Error Identification (SC 3.3.1)

Form errors must be identified in text (not just colour) and describe what the error is.

<!-- After form submission with errors -->
<div role="alert" aria-live="assertive">
  <h2>Please fix the following errors:</h2>
  <ul>
    <li><a href="#email">Email: Please enter a valid email address</a></li>
    <li><a href="#phone">Phone: Phone number must be 10 digits</a></li>
  </ul>
</div>

Labels for All Inputs (SC 1.3.1 / 3.3.2)

Every form input must have a programmatically associated label. Placeholder text is not a substitute for a label.

<!-- Bad: no label -->
<input type="email" placeholder="Email address">

<!-- Good: label element -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

<!-- Good: aria-label (when visual label not possible) -->
<input type="search" aria-label="Search the site" placeholder="Search...">

5. Robust

Valid HTML (SC 4.1.1)

Run your HTML through the W3C Validator (validator.w3.org). Duplicate IDs, unclosed elements, and invalid nesting all create unpredictable behaviour for assistive technologies.

Name, Role, Value (SC 4.1.2)

Every UI component must have:
– An accessible name (what it’s called)
– A role (what type of thing it is)
– A value/state (its current state, where applicable)

☰

Status Messages (SC 4.1.3)

Status messages (success notifications, error messages, loading indicators) must be programmatically determinable so screen readers can announce them without requiring focus change.

6. Semantic HTML: The Foundation of Accessibility

Semantic HTML is the single highest-leverage accessibility investment. It provides meaning, structure, and navigational landmarks to assistive technologies — for free.

Heading Hierarchy

<!-- Page structure -->
<h1>Main Page Topic</h1>  <!-- One per page -->
  <h2>Major Section</h2>
    <h3>Sub-section</h3>
    <h3>Sub-section</h3>
  <h2>Second Major Section</h2>

Never use headings purely for visual size. Don’t skip levels (h1 → h3). Screen reader users navigate by headings — the hierarchy is their table of contents.

Landmark Regions

<header>  <!-- Banner landmark -->
  <nav aria-label="Main navigation">  <!-- Navigation landmark -->
    <!-- nav items -->
  </nav>
</header>

<main>  <!-- Main landmark — only one per page -->
  <article>  <!-- Article: self-contained content -->
    <section aria-labelledby="services-heading">  <!-- Section with label -->
      <h2 id="services-heading">Our Services</h2>
    </section>
  </article>

  <aside>  <!-- Complementary landmark -->
    <!-- Sidebar content -->
  </aside>
</main>

<footer>  <!-- Contentinfo landmark -->
</footer>

Screen reader users can navigate directly to any landmark region. Sites without semantic landmarks force screen reader users to traverse every element from the top.

Button vs. Div vs. Link

Open modal

Contact us

7. ARIA Roles and When to Use Them

ARIA (Accessible Rich Internet Applications) provides semantic meaning to elements that HTML doesn’t cover natively. The cardinal rule of ARIA:

“No ARIA is better than bad ARIA.” (W3C)

Bad ARIA creates a worse experience than no ARIA. Use native HTML elements first.

Common ARIA Attributes

<!-- role: what the element is -->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">

<!-- aria-label: accessible name for element with no visible text -->
<button aria-label="Close dialog">×</button>

<!-- aria-labelledby: name provided by another element -->
<h2 id="dialog-title">Confirm Deletion</h2>
<div role="dialog" aria-labelledby="dialog-title">...</div>

<!-- aria-describedby: supplementary description -->
<input type="password" aria-describedby="pw-hint">
<p id="pw-hint">Minimum 8 characters, one number, one symbol.</p>

<!-- aria-expanded: state of collapsible elements -->
<button aria-expanded="false" aria-controls="menu-panel">Menu</button>
<div id="menu-panel" hidden>...</div>

<!-- aria-live: announce dynamic updates -->
<div aria-live="polite">Items in cart: 3</div>  <!-- Polite: waits for idle -->
<div aria-live="assertive">Session expiring in 60 seconds.</div>  <!-- Immediate -->

<!-- aria-hidden: hide decorative elements from AT -->
<span aria-hidden="true">→</span>

Tabindex Rules

<!-- Natural tab order: tabindex="0" (adds to natural order) -->
<div role="button" tabindex="0">Custom button</div>

<!-- Remove from tab order: tabindex="-1" (focusable via JS, not tab) -->
<div id="modal-panel" role="dialog" tabindex="-1">...</div>

<!-- NEVER use positive tabindex values (tabindex="1", "2" etc.) -->
<!-- They override natural order and create confusing tab sequences -->

8. Testing Tools and Testing Process

Automated Testing Tools

Axe DevTools (browser extension): Industry-standard accessibility linter. Run it on any page, get categorised issues with code references and remediation guidance. Free tier covers most WCAG A/AA issues. Best used in Chrome DevTools → Accessibility panel.

WAVE (Web Accessibility Evaluation Tool): Browser extension that overlays accessibility information visually on the page. Good for seeing structural issues (heading order, landmark regions, alt text).

Lighthouse Accessibility Audit: Built into Chrome DevTools → Lighthouse → Accessibility. Runs a subset of axe checks. Scores out of 100. Note: a Lighthouse score of 100 does not mean WCAG AA compliance — it’s an automated subset.

Pa11y (CLI): Run automated accessibility checks in your CI/CD pipeline.

npm install -g pa11y
pa11y https://yoursite.com --standard WCAG2AA --reporter json > accessibility-report.json

Manual Testing

Automated tools catch approximately 30-40% of WCAG issues. The rest require manual testing.

Keyboard-only navigation test (15-20 minutes):
1. Disconnect or ignore your mouse
2. Open your homepage
3. Press Tab — verify focus moves to skip link
4. Navigate through every interactive element
5. Fill out and submit all forms
6. Open and close any modals or dropdowns

Screen reader testing:
– Windows: NVDA (free) with Firefox, or JAWS with Chrome
– macOS/iOS: VoiceOver (built-in) — enable with Cmd+F5
– Android: TalkBack (built-in)
– Chrome extension: ChromeVox (for quick testing)

Test with real screen reader users if accessibility is critical for your audience. Your developers can’t fully simulate the lived experience of a screen reader user.

Colour Contrast Testing

• WebAIM Contrast Checker: webaim.org/resources/contrastchecker/
• Colour Contrast Analyser desktop app (free, TPGi)
• Figma: Contrast plugin, Stark plugin (for design files)
• Browser: Chrome DevTools → Elements → Styles → computed contrast ratio shown for text

9. Common Mistakes and How to Fix Them

10. Interactive Tools

Tool 1: WCAG 2.1 AA Accessibility Checklist

Tool 2: Colour Contrast Checker

FAQ

Q: Is WCAG 2.1 AA a legal requirement?
A: In the US, ADA Title III has been interpreted by courts to require website accessibility, and WCAG 2.1 AA is the accepted standard for compliance. In the EU, the European Accessibility Act mandates it for private sector digital services from 2025. In Australia, the DDA applies. Legal risk is real, particularly for US businesses with public-facing websites.

Q: Can automated tools catch all accessibility issues?
A: No. Automated tools like axe and Lighthouse catch approximately 30-40% of WCAG issues. The remainder require manual testing — keyboard navigation, screen reader testing, and cognitive accessibility evaluation. Automated scans are a starting point, not a compliance certification.

Q: What’s the difference between WCAG 2.1 and WCAG 2.2?
A: WCAG 2.2 (2023) adds 9 new success criteria, most notably Focus Appearance (2.4.11 — better visible focus indicators) and Dragging Movements (2.5.7 — keyboard alternatives for drag interactions). Most legal requirements still reference WCAG 2.1. Implement 2.2 criteria as best practice.

Q: Does improving accessibility hurt visual design?
A: No, when done correctly. Many of the most successful design systems (Apple HIG, Material Design, GOV.UK Design System) are fully accessible and visually excellent. The constraint of accessible contrast ratios and clear hierarchy often produces cleaner, more readable designs. The “accessibility vs aesthetics” tradeoff is a false dichotomy.

Q: How often should we audit for accessibility?
A: Run automated axe checks in your CI/CD pipeline on every pull request. Do a full manual audit every 6-12 months, and after every major redesign. Accessibility regressions are common when non-accessibility-trained developers make changes.

Q: How much does making a site accessible cost?
A: Building accessibly from the start adds approximately 10-20% to development time. Retrofitting an existing inaccessible site can cost 2-5x more. This is the strongest argument for accessibility-first development — the cost of doing it right is a fraction of the cost of doing it twice.

Conclusion

Accessibility is not a checkbox — it’s a design practice that, when embedded from the start, produces better experiences for all users: cleaner semantics, more navigable structure, more readable typography, and more usable interactive components.

The WCAG 2.1 AA standard is achievable for any website with the right approach: semantic HTML first, colour contrast checking in design, keyboard testing before release, and automated scanning in your CI pipeline.

Need a web development team that builds accessibility into the process from day one? Ignited Nepal’s web development team delivers WCAG 2.1 AA compliant websites for businesses that can’t afford exclusion.

Written by the Ignited Nepal team. ignitednepal.com