Forem: Zdenek Spacek

The April 2026 ADA Deadline: What Developers Actually Need to Know

Zdenek Spacek — Mon, 16 Feb 2026 08:46:13 +0000

The internet is full of panicky articles about the April 24, 2026 ADA deadline. Most of them are trying to sell you something. Here's what's actually happening, who it affects, and what you should do about it. From a developer's perspective.

What's the Deadline?

On April 24, 2026, state and local government entities serving populations of 50,000+ must have web content and mobile apps that conform to WCAG 2.1 Level AA.

Smaller entities (under 50,000) get until April 26, 2028.

This is a DOJ rule under Title II of the ADA (which covers government entities).

Does This Apply to Private Businesses?

Not directly. The April 2026 rule specifically targets government entities.

But here's the nuance that matters: Title III of the ADA covers "places of public accommodation". And courts have increasingly ruled that websites fall into this category. Over 4,000 ADA website accessibility lawsuits were filed against private businesses in 2023 alone.

The April deadline doesn't create new obligations for private businesses. But it:

Sets WCAG 2.1 AA as the explicit standard (previously it was implied)
Increases public awareness
Gives plaintiff attorneys more ammunition

If you build websites for clients, expect more questions about this.

For EU Developers: You're Already Late

The European Accessibility Act (EAA) deadline was June 28, 2025. It's already passed. The EAA applies to ALL private businesses selling products or services in the EU. If your client has EU customers, they should already be compliant.

What WCAG 2.1 AA Actually Requires

Skip the 78-page spec. Here's what matters for developers:

The Big 5 (fix these and you're 70% there)

Alt text on images — Every non-decorative <img> needs alt. Decorative images get alt="".
Form labels — Every <input>, <select>, <textarea> needs an associated <label> or aria-label.
Color contrast — Text needs 4.5:1 ratio against background (3:1 for large text). Use WebAIM's contrast checker.
Keyboard navigation — Every interactive element must be reachable and usable via keyboard alone. Tab order should be logical.
Heading hierarchy — Use <h1> through <h6> in order. Don't skip levels. Don't use headings just for styling.

The Next 5 (for AA compliance)

Language declaration — <html lang="en"> (or appropriate language code)
Link purpose — Links should make sense out of context. No "click here."
Error identification — Form errors must be clearly described in text.
Resize support — Content usable at 200% zoom without horizontal scrolling.
Focus visibility — Interactive elements must have visible focus indicators.

What NOT to Do

Don't Install an Accessibility Widget

AccessiBe was fined $1 million by the FTC in 2024 for making false claims about their AI-powered accessibility widget. Overlay widgets:

Don't fix underlying code issues
Can interfere with actual assistive technology
Give a false sense of compliance
Won't protect you in a lawsuit

Don't Panic-Buy an Enterprise Tool

If you're a solo dev or small agency, you don't need Siteimprove ($5k+/year) or Level Access. A good scanner + manual testing covers most needs.

Don't Ignore It

"We'll deal with it later" is how businesses get demand letters. The basics take a few hours to fix.

What TO Do

1. Scan Your Sites

Run an automated scan to find the low-hanging fruit. Tools:

AccessiGuard — free scan, 22 WCAG checks (full disclosure: I built this)
WAVE — browser extension
axe DevTools — Chrome extension
Lighthouse (built into Chrome DevTools)

No single tool catches everything. Use 2-3.

2. Fix the Automated Issues

Alt text, labels, headings, lang attribute — these are mechanical fixes. A developer can knock out 80% of automated issues in a day.

3. Manual Testing

Automated tools catch ~30-40% of issues. For the rest:

Keyboard test: Tab through your entire site without a mouse
Screen reader test: Try NVDA (Windows) or VoiceOver (Mac) on key pages
Zoom test: Set browser to 200% zoom and check layout

4. Set Up Monitoring

Accessibility is ongoing. Sites change. New content gets added. A monthly scan catches regressions before they become problems.

The Business Case (For When Clients Push Back)

Legal risk: Average ADA settlement is $5,000-25,000. Annual scanning costs $348.
Market size: 26% of US adults have a disability (CDC). That's customers you're excluding.
SEO benefit: Many accessibility improvements (alt text, headings, semantic HTML) directly improve SEO.
April 24 creates urgency: Even if the rule doesn't directly apply, the attention spike increases lawsuit risk.

TL;DR

April 24, 2026 deadline is for government entities, but affects everyone indirectly
WCAG 2.1 AA is the standard — fix alt text, labels, contrast, keyboard nav, headings
Don't buy widgets. Do fix your code.
Scan → fix → test manually → monitor

How to Do a Website Accessibility Audit in 2026: A Step-by-Step Guide

Zdenek Spacek — Fri, 13 Feb 2026 08:46:24 +0000

Whether you're preparing for the April 2026 ADA deadline, the European Accessibility Act, or simply want to make your website usable by everyone — the first step is always the same: an accessibility audit.

But where do you start? What do you check? And how do you prioritize what to fix first?

This guide walks you through a complete website accessibility audit, step by step.

What Is a Website Accessibility Audit?

An accessibility audit is a systematic review of your website against established standards — typically WCAG 2.1 Level AA — to identify barriers that prevent people with disabilities from using your site.

A thorough audit combines:

Automated scanning — tools that crawl your pages and flag code-level issues
Manual testing — human review of keyboard navigation, screen reader compatibility, and user experience
Assistive technology testing — verifying your site works with screen readers, voice control, and other tools

No single method catches everything. Automated tools find roughly 30-50% of WCAG issues. The rest requires human judgment.

Step 1: Define Your Scope

Before scanning anything, decide what you're auditing:

Full site or key pages? For large sites, start with your most critical user journeys: homepage, navigation, signup/login, checkout, contact forms, and your top 10 most-visited pages.
Which standard? WCAG 2.1 Level AA is the legal benchmark in most jurisdictions. Level AAA is aspirational but rarely required.
Mobile too? Responsive design issues often create accessibility barriers. Test at multiple breakpoints.

Tip: Document your scope. You'll need it for compliance records and to track progress over time.

Step 2: Run an Automated Scan

Start with automated tools to get a baseline. This catches the "low-hanging fruit" — issues that are clearly detectable in code.

What automated scans catch well:

Missing alt text on images
Poor color contrast ratios
Missing form labels
Incorrect heading hierarchy
Missing document language
ARIA attribute errors
Empty links and buttons

What they miss:

Whether alt text is actually meaningful
Keyboard trap issues in complex widgets
Logical reading order
Context-dependent issues (like whether a link makes sense out of context)
Dynamic content and single-page app interactions

How to scan with AccessiGuard

Go to accessiguard.app and enter your URL
Our scanner crawls your pages and tests against WCAG 2.1 criteria
Review the report — issues are categorized by severity and WCAG success criterion
Export or share the report with your development team

A free scan gives you an immediate snapshot. Paid plans add multi-page scanning, monitoring, and historical tracking.

Step 3: Manual Keyboard Testing

This is where you find the issues automated tools can't. Put your mouse aside and try to use your entire site with only your keyboard.

What to test:

Tab order: Press Tab repeatedly. Does focus move through the page in a logical order? Can you reach every interactive element (links, buttons, form fields, menus)?

Focus visibility: Can you always see where you are on the page? A visible focus indicator (outline, highlight) should be present on every focused element.

Keyboard traps: Can you always Tab out of every component? Modal dialogs, dropdown menus, and embedded content (like maps or videos) are common trap points.

Skip navigation: Does the site have a "Skip to main content" link that appears when you first press Tab? Without it, keyboard users must tab through the entire header on every page.

Interactive elements: Can you open menus, submit forms, activate buttons, and close dialogs using only Enter, Space, Escape, and arrow keys?

Common keyboard failures:

Custom dropdown menus that only respond to mouse clicks
Modal dialogs that don't trap focus (focus escapes behind the overlay)
Carousels with no keyboard controls
"Click here" elements built with <div> instead of <button>

Step 4: Screen Reader Testing

Test with at least one screen reader to understand how assistive technology users experience your site.

Free screen reader options:

NVDA (Windows) — free, widely used
VoiceOver (macOS/iOS) — built into Apple devices, activate with Cmd+F5
TalkBack (Android) — built into Android devices

What to listen for:

Images: Are they described? Do decorative images get skipped?
Headings: Does the heading structure make sense when navigated by heading?
Forms: Are labels announced when you focus each field? Are error messages associated with the correct field?
Links: Do link texts make sense without surrounding context?
Landmarks: Can the screen reader identify page regions (header, nav, main, footer)?
Dynamic content: When content updates (notifications, live regions, loading states), is the screen reader notified?

Step 5: Check Color and Visual Design

Visual accessibility goes beyond color contrast.

Color contrast

Text must meet minimum contrast ratios against its background:

Normal text: 4.5:1 ratio (WCAG AA)
Large text (18px+ bold or 24px+ regular): 3:1 ratio
UI components and graphics: 3:1 ratio against adjacent colors

Use tools like the WebAIM Contrast Checker to verify.

Beyond contrast:

Don't rely on color alone to convey information (red/green for error/success). Add icons, text, or patterns.
Text resizing: Does your layout hold up at 200% zoom? Users with low vision depend on this.
Motion: Can animations and auto-playing content be paused? Some users experience vestibular disorders.

Step 6: Test Forms and Error Handling

Forms are where accessibility failures have the most direct impact — they block users from signing up, purchasing, or contacting you.

Checklist:

Every input has a visible, programmatically associated <label>
Required fields are indicated (not just with color)
Error messages are specific ("Email format is invalid" not just "Error")
Errors are associated with the correct field (via aria-describedby)
Focus moves to the first error when a form submission fails
Success confirmation is announced to screen readers
Autocomplete attributes are used where appropriate (autocomplete="email", etc.)

Step 7: Review Media Content

Images

Informative images have descriptive alt text
Decorative images have empty alt="" (so screen readers skip them)
Complex images (charts, infographics) have extended descriptions

Video

Captions are provided for all pre-recorded video
Audio descriptions are available for video content where the visual information isn't conveyed through audio alone
Auto-playing video can be paused

Audio

Transcripts are provided for audio-only content (podcasts, audio clips)

Step 8: Prioritize and Fix

You'll likely find dozens (or hundreds) of issues. Don't panic. Prioritize by impact:

Fix first (Critical):

Keyboard traps — users literally can't proceed
Missing form labels — forms are unusable
No focus indicators — keyboard users are lost
Auto-playing audio/video that can't be stopped

Fix next (High):

Missing alt text on informative images
Poor color contrast on body text
Heading hierarchy issues
Missing skip navigation

Fix later (Medium):

Decorative images with non-empty alt text
Minor contrast issues on non-essential elements
Missing autocomplete attributes
Inconsistent focus styles

Step 9: Document and Monitor

An audit isn't a one-time event. Accessibility is ongoing.

Save your baseline report — you need to show progress
Set up monitoring — new code deployments can introduce regressions
Create an accessibility statement — publish your commitment and contact info for feedback
Schedule regular audits — quarterly automated scans plus semi-annual manual reviews is a reasonable cadence

How Long Does an Audit Take?

Site Size	Automated Scan	Manual Review	Total
Small (5-10 pages)	5 minutes	2-4 hours	Half a day
Medium (50-100 pages)	15 minutes	1-2 days	2-3 days
Large (500+ pages)	30-60 minutes	1-2 weeks	2-3 weeks

Automated scanning is fast. The manual review is where the real time goes — and where the most impactful issues are found.

Start Your Audit Now

The best time to audit your website was before you launched. The second best time is now.

Run a free scan to get your baseline
Follow this guide for manual testing
Prioritize fixes by impact
Set up monitoring to catch regressions

With the ADA deadline approaching and accessibility lawsuits surging, proactive auditing isn't just good practice — it's risk management.

Need help interpreting your scan results? Reach out at support@accessiguard.app — happy to help.

I Built a Free WCAG Accessibility Scanner — Here's What I Learned

Zdenek Spacek — Thu, 12 Feb 2026 12:59:57 +0000

As a solo developer building in public, I recently launched AccessiGuard — a free WCAG accessibility scanner. What started as a side project to help developers catch accessibility issues early has taught me more about web standards, automated testing, and edge cases than I ever expected.

Here's the technical journey, the challenges I faced, and what I learned along the way.

Why Another Accessibility Tool?

The accessibility landscape is changing fast. The EU's European Accessibility Act (EAA) is already in effect, and US government entities face an April 2026 deadline for WCAG compliance. Just last year, accessiBe was fined $1 million by the FTC for misleading accessibility claims.

I wanted to build something honest: a tool that tells you what it actually checks, doesn't make inflated promises, and remains free for developers who want to catch issues before they become lawsuits.

The Tech Stack

I kept it intentionally simple:

Next.js 14 (App Router) — for the web interface and API routes
Cheerio — for fast, server-side HTML parsing
TypeScript — because accessibility checks require precision
React — for the frontend dashboard
Vercel — for hosting and edge functions

The beauty of Cheerio over a full browser automation tool like Puppeteer is speed. We can parse and analyze HTML in milliseconds rather than seconds. The tradeoff? We can't check everything that requires JavaScript execution or visual rendering.

What We Actually Check

I'll be honest: automated tools can only catch about 30-40% of WCAG issues. The rest require human judgment. But that 30-40% matters — those are the low-hanging fruit that plague most websites.

Here's what AccessiGuard scans for:

1. Missing Alt Text on Images

This is the most common issue. Here's a simplified version of the check:

function checkImageAlt($) {
  const issues = [];

  $('img').each((i, elem) => {
    const $img = $(elem);
    const alt = $img.attr('alt');
    const role = $img.attr('role');

    // Decorative images should have empty alt or role="presentation"
    if (role === 'presentation' || role === 'none') {
      return; // Skip
    }

    // Non-decorative images must have alt text
    if (alt === undefined) {
      issues.push({
        type: 'missing-alt',
        element: $.html($img),
        wcag: '1.1.1',
        level: 'A'
      });
    }
  });

  return issues;
}

Challenge faced: Distinguishing between truly missing alt attributes and intentionally empty ones (alt=""). Empty alt is valid for decorative images, but missing alt is always an error.

2. Form Labels

Forms are critical for accessibility. Every input needs a label:

function checkFormLabels($) {
  const issues = [];

  $('input, select, textarea').each((i, elem) => {
    const $input = $(elem);
    const id = $input.attr('id');
    const ariaLabel = $input.attr('aria-label');
    const ariaLabelledby = $input.attr('aria-labelledby');
    const type = $input.attr('type');

    // Skip hidden inputs and buttons
    if (type === 'hidden' || type === 'submit' || type === 'button') {
      return;
    }

    // Check for label association
    const hasLabel = id && $(`label[for="${id}"]`).length > 0;
    const hasAriaLabel = ariaLabel || ariaLabelledby;

    if (!hasLabel && !hasAriaLabel) {
      issues.push({
        type: 'missing-form-label',
        element: $.html($input),
        wcag: '3.3.2',
        level: 'A'
      });
    }
  });

  return issues;
}

Challenge faced: Modern frameworks like React often use aria-label or wrap inputs in labels without for attributes. I had to account for multiple valid labeling patterns.

3. Heading Hierarchy

Headings should follow a logical order (h1 → h2 → h3), not skip levels:

function checkHeadingOrder($) {
  const issues = [];
  const headings = [];

  $('h1, h2, h3, h4, h5, h6').each((i, elem) => {
    const level = parseInt(elem.name.substring(1));
    headings.push({ level, text: $(elem).text().trim() });
  });

  for (let i = 1; i < headings.length; i++) {
    const current = headings[i].level;
    const previous = headings[i - 1].level;

    // Check if we skip levels (e.g., h2 → h4)
    if (current - previous > 1) {
      issues.push({
        type: 'heading-skip',
        message: `Heading level ${current} appears after level ${previous}`,
        wcag: '1.3.1',
        level: 'A'
      });
    }
  }

  return issues;
}

Challenge faced: Some modern designs intentionally use CSS to style headings differently than their semantic level. I had to decide whether to flag semantic issues or trust the developer's intent.

4. Color Contrast

This is where it gets tricky. Without rendering the page, we can't truly measure contrast. So AccessiGuard:

Parses inline styles and <style> tags
Flags suspicious color combinations
Recommends manual testing with browser DevTools

function checkColorContrast($) {
  const warnings = [];

  $('[style*="color"]').each((i, elem) => {
    const $elem = $(elem);
    const style = $elem.attr('style');

    // Simple regex to extract colors (not production-ready)
    const colorMatch = style.match(/color:\s*([^;]+)/);
    const bgMatch = style.match(/background(-color)?:\s*([^;]+)/);

    if (colorMatch && bgMatch) {
      warnings.push({
        type: 'contrast-warning',
        message: 'Manual contrast check recommended',
        element: $.html($elem),
        wcag: '1.4.3',
        level: 'AA'
      });
    }
  });

  return warnings;
}

Challenge faced: Accurate contrast calculation requires computed styles from a rendered page. I chose to flag potential issues and recommend tools like WAVE or Axe DevTools for final verification.

5. Language Declaration

Simple but critical:

function checkLanguage($) {
  const issues = [];
  const htmlLang = $('html').attr('lang');

  if (!htmlLang) {
    issues.push({
      type: 'missing-lang',
      message: 'HTML element missing lang attribute',
      wcag: '3.1.1',
      level: 'A'
    });
  }

  return issues;
}

The Architecture

Here's how a scan works:

User submits URL via the Next.js frontend
API route (/api/scan) receives the request
Fetch HTML using native fetch() with a 10-second timeout
Parse with Cheerio — convert HTML string to queryable DOM
Run checks — all check functions execute in parallel
Aggregate results — combine issues by severity (A, AA, AAA)
Return JSON — frontend displays results

The entire scan typically takes 500ms to 2 seconds, depending on page size.

Edge Cases and Gotchas

SVGs with `<title>` elements

Screen readers handle SVG accessibility differently across browsers. I initially flagged SVGs without aria-label, but missed that <title> elements inside SVGs are valid accessible names.

Dynamic Content

Single-page apps (SPAs) often render content client-side. Cheerio only sees the initial HTML. Solution: I added a notice recommending browser-based tools (Axe DevTools, Lighthouse) for SPA testing.

Iframe Content

Iframes are separate documents. I can detect their presence but can't scan cross-origin content without violating CORS. I flag this limitation in the report.

ARIA Overrides

If an element has aria-hidden="true", it's invisible to screen readers — even if it has other accessibility issues. I had to adjust checks to respect ARIA states.

What I'd Do Differently

Use a headless browser for premium scans. Cheerio is fast but limited. For a paid tier, I'd add Playwright or Puppeteer to check rendered styles, computed contrast, and JavaScript-generated content.

Add axe-core integration. The axe-core library is battle-tested and catches issues I haven't coded for yet. I wanted to build the core myself first to learn, but I'll likely integrate it soon.

More granular reporting. Right now, results are grouped by WCAG level. I should add filtering by issue type, element, and page section.

Lessons Learned

Accessibility is hard. Even automated checks require nuance. There's no one-size-fits-all rule.
Be honest about limitations. Users trust tools that admit what they can't do.
Speed matters. Developers won't use a slow tool. Cheerio's simplicity pays off.
Edge cases are infinite. Every new scan reveals a pattern I didn't anticipate.

What's Already Live

Since the initial build, I've shipped:

Continuous monitoring — scheduled scans with email alerts (paid tiers at $29/$79/$199/month)
Historical tracking — see how your accessibility score changes over time
Multi-page scans — crawl entire sites, not just one page
AI-powered fix suggestions — actionable code snippets to resolve each issue

What's Next

What I'm working on now:

PDF compliance reports — downloadable, shareable with clients or legal
CI/CD integration — GitHub Action to catch accessibility regressions before deploy
EU localization — Czech/German landing pages for the European market

Try It Yourself

AccessiGuard is free and always will be for single scans. No signup required.

👉 accessiguard.app

Scan your site, get actionable feedback, and fix issues before they become problems.

Building in public as a solo founder. If you have feedback, questions, or want to discuss accessibility testing, drop a comment below. I read and respond to everything.

Want more technical deep-dives? Follow me here on Dev.to. Next up: "How I Built Continuous Accessibility Monitoring with Cron Jobs and Serverless Functions."