Web Accessibility Testing: Free Tools and Best Practices

About 16% of the world's population has a significant disability. That is roughly 1.3 billion people. In the United States alone, 27% of adults have some type of disability according to the CDC. These are not edge cases. When a website is inaccessible, it locks out a larger audience than the entire population of Europe.

And yet, a 2025 WebAIM analysis of one million homepages found an average of 56.8 detectable accessibility errors per page. The most common issue — low contrast text — appeared on 81% of pages. These are not obscure technical violations. They are problems that make text physically unreadable for millions of people.

The frustrating part is that most accessibility issues are easy to fix once you know they exist. The hard part is finding them. This guide covers the practical tools and techniques for testing web accessibility, focused on things you can do today without buying specialized software.

Color Contrast: The Single Biggest Accessibility Failure

WCAG 2.1 specifies minimum contrast ratios between text and its background. The requirements are concrete and measurable:

• AA (normal text): 4.5:1 contrast ratio
• AA (large text, 18px+ or 14px+ bold): 3:1 contrast ratio
• AAA (enhanced, normal text): 7:1 contrast ratio
• AAA (enhanced, large text): 4.5:1 contrast ratio

What does this mean in practice? Light gray text (#999) on a white background (#FFF) has a contrast ratio of 2.85:1 — it fails even the minimum AA standard. That elegant, subtle gray that designers love is literally unreadable for people with low vision, and hard to read for everyone else in bright sunlight or on a low-quality monitor.

The Color Contrast Checker takes a foreground and background color, calculates the exact contrast ratio, and shows whether it passes WCAG AA and AAA standards. It also simulates how the color combination looks to people with different types of color blindness — protanopia (red-blind), deuteranopia (green-blind), and tritanopia (blue-blind).

Common contrast failures developers overlook

• Placeholder text in form inputs. The default browser placeholder color is often too light. Override it with ::placeholder { color: #767676; } or darker.
• Text over images. Text might have sufficient contrast in one area of the photo but not another. Add a semi-transparent overlay or text shadow to guarantee readability.
• Disabled button states. Disabled buttons are intentionally dimmed, but they still need enough contrast for users to read what the button says. WCAG does not exempt disabled elements from contrast requirements — it's a common misconception.
• Links that rely only on color. If the only difference between link text and surrounding text is color, color-blind users cannot distinguish them. Add an underline, bold weight, or other visual indicator.

HTML Accessibility: Semantic Structure Matters

Screen readers do not see your beautiful design. They read the HTML structure: headings, landmarks, lists, links, form labels, and ARIA attributes. If the HTML structure is wrong, the screen reader experience is wrong — regardless of how the page looks visually.

The HTML Accessibility Checker analyzes your markup for common accessibility issues. Paste in your HTML and it flags problems like missing alt attributes, empty links, missing form labels, incorrect heading hierarchy, and absent landmark regions.

The most impactful HTML fixes

1. Form labels

Every form input needs a visible label connected via the for attribute or by wrapping the input inside the <label> element. Placeholder text is NOT a label — it disappears when the user starts typing, leaving them with no indication of what the field expects.

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

<!-- Good: explicit label -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="jane@example.com">

2. Image alt text

Every <img> needs an alt attribute. Decorative images get alt="" (empty, not missing). Informative images get a description of what the image conveys, not what the image IS.

<!-- Bad: describes the file -->
<img src="chart.png" alt="chart.png">

<!-- Bad: too vague -->
<img src="chart.png" alt="chart">

<!-- Good: describes the information -->
<img src="chart.png" alt="Revenue growth from $2M to $5M between 2024 and 2026">

<!-- Good: decorative, empty alt -->
<img src="decorative-border.svg" alt="">

3. Heading hierarchy

Headings should follow a logical order: H1, then H2, then H3 under that H2, etc. Screen reader users navigate by heading level — jumping from H2 to H2 to scan the page, then diving into H3s within a section of interest. Skipping levels (H1 to H3 with no H2) breaks this navigation pattern.

4. Landmark regions

HTML5 landmark elements — <header>, <nav>, <main>, <aside>, <footer> — let screen reader users jump directly to major page sections. A page without landmarks forces the user to read through everything sequentially to find the main content.

<header>...site branding and navigation...</header>
<main>...primary page content...</main>
<aside>...sidebar, related links...</aside>
<footer>...copyright, links...</footer>

ARIA: When HTML Semantics Are Not Enough

ARIA (Accessible Rich Internet Applications) attributes fill the gaps where native HTML elements do not convey enough information to assistive technology. The first rule of ARIA is: do not use ARIA if native HTML can do the job. A <button> element is already accessible. Adding role="button" to a <div> is a workaround for not using the right element in the first place.

The ARIA Reference tool provides a searchable guide to ARIA roles, states, and properties. When you need to make a custom component accessible — a dropdown menu, a modal dialog, a tab panel, a drag-and-drop interface — the reference shows which ARIA attributes apply and how to implement them correctly.

ARIA patterns that come up constantly

• Modal dialogs: role="dialog", aria-modal="true", aria-labelledby pointing to the dialog title. Trap focus inside the dialog when it is open.
• Tab panels: role="tablist" on the container, role="tab" on each tab, role="tabpanel" on each panel. Arrow keys should switch between tabs.
• Live regions: aria-live="polite" on elements that update dynamically (toast notifications, search result counts, form validation messages). Screen readers announce these changes without the user navigating to them.
• Expandable sections: aria-expanded="true/false" on the trigger button, aria-controls pointing to the expandable content's ID.

Keyboard Navigation: The Overlooked Test

Try navigating your website using only the keyboard: Tab to move forward, Shift+Tab to move backward, Enter to activate links and buttons, Escape to close modals. If you cannot complete every task that a mouse user can, your site has keyboard accessibility issues.

What to look for

• Focus visibility. Can you see where the focus is at all times? If the default browser focus outline has been removed (the infamous outline: none in CSS) without a replacement, keyboard users are navigating blind.
• Focus order. Does Tab move through elements in a logical order? Absolute positioning and flexbox order can create a visual layout that differs from the DOM order, confusing keyboard navigation.
• Focus traps. Can focus get stuck in a component with no way to Tab out? This happens with poorly implemented modals, embedded iframes, and some third-party widgets.
• Skip links. A "Skip to main content" link as the first focusable element lets keyboard users bypass the navigation and jump directly to the page content. Without it, a user must Tab through every navigation link on every page.

Custom interactive elements

Native HTML buttons, links, and form controls are keyboard-accessible by default. Custom components built from <div> and <span> elements are not. If you build a custom dropdown, accordion, slider, or tab component, you must manually add:

• tabindex="0" to make it focusable
• Keyboard event handlers (Enter, Space, Arrow keys as appropriate)
• ARIA roles and states to convey the component's purpose
• Visible focus styling

Testing Methodology: A Practical Approach

Level 1: Automated scanning (catches ~30% of issues)

Run your HTML through the HTML Accessibility Checker. This catches missing alt text, empty links, missing labels, heading issues, and other machine-detectable problems. These are the low-hanging fruit.

Level 2: Color and visual testing (catches ~20% more)

Check every text/background combination with the Color Contrast Checker. Do not forget hover states, active states, focus states, and error messages — these often have different colors than the default state. Check your entire palette against color blindness simulations.

Level 3: Keyboard testing (catches ~20% more)

Navigate the entire page with only the keyboard. Complete every interactive task: fill forms, open menus, navigate tabs, trigger buttons, close modals. Note everywhere you get stuck, lose focus visibility, or encounter unexpected behavior.

Level 4: Screen reader testing (catches the remaining ~30%)

Use VoiceOver (macOS, built-in), NVDA (Windows, free), or TalkBack (Android, built-in) to navigate your page. Listen to how the page is announced. Does the heading structure make sense? Are images described usefully? Do form fields announce their labels? Do dynamic updates get announced?

This is the test that reveals the most surprising issues. A page that looks perfect visually and passes automated tests can still be completely confusing when read aloud.

The Business Case for Accessibility

Beyond the ethical argument, accessibility has concrete business impacts:

• Legal risk. ADA lawsuits against websites exceeded 4,000 in 2025 in the US alone. The EU's European Accessibility Act takes full effect in June 2025, covering e-commerce, banking, and public services.
• SEO benefits. Accessible websites tend to rank better. Semantic HTML, descriptive alt text, clear heading structure, and fast load times are both accessibility requirements and SEO best practices.
• Broader audience. Accessibility improvements help everyone: captions help in noisy environments, high contrast helps in sunlight, keyboard navigation helps power users, clear layouts help on small screens.
• Government contracts. Section 508 compliance is required for any technology used by or sold to the US federal government.

Quick Wins: Fix These Today

If you only have 30 minutes, these five fixes address the most common accessibility failures:

1. Add alt text to all images. Decorative images get alt="". Meaningful images get descriptions.
2. Check and fix contrast ratios. Every text/background combination needs at least 4.5:1 for normal text.
3. Label all form fields. Every input, select, and textarea needs a visible <label>.
4. Add a skip link. <a class="skip-to-content" href="#main-content">Skip to content</a> as the first element in the body.
5. Restore focus outlines. If your CSS has *:focus { outline: none }, remove it or replace it with a visible custom focus style.

Frequently Asked Questions

What WCAG level should I target?

WCAG AA is the standard that most laws reference and most organizations target. AAA is aspirational and not required for legal compliance in most jurisdictions. Start with AA. Get that solid before worrying about AAA.

Can automated tools catch all accessibility issues?

No. Automated testing catches about 30-40% of WCAG violations — the ones that are machine-detectable (missing alt text, contrast ratios, missing labels). The remaining 60-70% require human judgment: is the alt text actually useful? Does the page make sense when read in order? Is the keyboard navigation logical?

Do I need to make everything accessible?

Yes, to WCAG AA level. There are narrow exceptions (live video captions for non-essential content, for example), but the default expectation is that all public-facing web content meets AA standards. This is not just a legal requirement in many jurisdictions — it is the baseline for a usable web.

Accessibility Testing Tools

• HTML Accessibility Checker — scan markup for missing labels, alt text, headings, and landmarks
• Color Contrast Checker — WCAG AA/AAA compliance with color blindness simulation
• ARIA Reference — searchable guide to roles, states, and properties for custom components

For more on accessible design, the Color Blindness Accessibility guide dives deeper into designing for color vision deficiency. The Color Theory for Designers guide covers contrast, palette generation, and WCAG compliance from a design perspective.