Testing Accessibility Without an Accessibility Testing Tool

Automated accessibility tools (axe, WAVE, Lighthouse, Pa11y) catch 30–50% of WCAG issues. The other 50–70% requires a human — someone who can turn off their mouse, unplug the CSS, or try to fill out a form with a screen reader running. The good news is that most of those human tests require no specialized software, no subscription, and no expertise in HTML or CSS. What they require is half an hour and a willingness to use your own site the way a user with a disability would.

This guide covers six manual tests anyone can perform today, plus a short list of free browser-based helpers (not paid testing tools) that make the process faster. Combined, they’ll catch more real problems than most automated scans — and they’ll give you the context automated tools can’t: what the experience actually feels like for someone using assistive technology.

Why accessibility testing matters in 2026

Accessibility is simultaneously a business concern, a legal concern, and an ethical one. Business-wise, the CDC reports that roughly 1 in 4 US adults lives with some form of disability — permanent, temporary, or situational. A site inaccessible to them isn’t just excluding a minority; it’s failing a quarter of the potential audience. Conversion loss at that scale dwarfs the cost of fixing it.

Legally, three frameworks have sharpened in the last two years:

• Americans with Disabilities Act (ADA) — US civil rights law. ADA lawsuits against websites crossed 4,000+ per year as of 2024, with ongoing litigation pressure on e-commerce, healthcare, and education sites.
• DOJ April 2024 Final Rule — explicitly applies ADA Title II to state and local government websites and mobile apps, requiring WCAG 2.1 AA compliance by April 2026 (large entities) or April 2027 (small).
• European Accessibility Act (EAA) — enforcement began June 28, 2025, and now covers most e-commerce, banking, transport, and communications services serving EU consumers. Penalties vary by member state but reach into the millions of euros.
• Section 508 — applies to US federal agencies and contractors; aligned with WCAG 2.0 AA since the 2018 refresh.
• Rehabilitation Act (1973) — the predecessor civil rights framework that established Section 504 (broad disability non-discrimination in federally-funded programs) and Section 508.

The standard referenced by all of these is the Web Content Accessibility Guidelines (WCAG), published by the W3C. WCAG 2.2 (published October 5, 2023) is the current version and adds nine new success criteria over WCAG 2.1, including Focus Not Obscured, Target Size (Minimum), and Consistent Help. WCAG 3.0 is in development but years from being the operative standard. Most legal requirements still reference WCAG 2.1 AA; conforming to 2.2 AA is a reasonable forward-looking target.

WCAG’s four principles spell out as POUR:

• Perceivable — users can perceive the content (text alternatives, captions, sufficient contrast).
• Operable — users can operate the interface (keyboard access, enough time, no seizure-triggering content).
• Understandable — content and interface are understandable (readable language, predictable behavior, clear error messages).
• Robust — content works with assistive technologies (screen readers, voice control, switch devices).

Why not just use online tools?

Automated accessibility scanners are genuinely useful — they catch structural issues at scale, run on every deploy, and cost little or nothing for basic use. What they can’t do is judge whether alt text is accurate, whether a labeled button makes sense, or whether a complex interaction actually works for a keyboard-only user. Studies consistently find automated tools catch somewhere between 30% and 50% of WCAG issues; the remainder requires human judgment.

So the honest framing isn’t “manual testing instead of automated tools” — it’s “manual testing alongside automated tools, because neither alone is sufficient.” The six techniques below are the human half of that pairing.

1. Test with keyboard only

Unplug your mouse, or set your trackpad aside. Navigate the site using only keyboard controls:

• Tab moves to the next interactive element.
• Shift+Tab moves to the previous one.
• Enter activates links and buttons.
• Space activates buttons and toggles checkboxes.
• Arrow keys navigate within menus, radio groups, and custom widgets.
• Esc closes modals and dismisses overlays.

What to look for:

• Every interactive element is reachable. If a menu, button, or link can’t be tabbed to, keyboard users can’t use it.
• The focus indicator is visible at all times — a clear outline, color change, or ring around the currently-focused element. This is WCAG 2.4.7 (Focus Visible) and 2.4.11 (Focus Not Obscured, new in WCAG 2.2).
• Focus order matches visual order — tabbing moves logically from top-left to bottom-right, not jumping around unpredictably.
• No keyboard traps — you can always tab out of any component. Modals should return focus to the trigger element when closed.
• Skip links work — most sites have a “Skip to main content” link that appears when focused. If yours doesn’t, add one. It saves keyboard users from tabbing through a 50-item menu on every page.

Keyboard-only navigation is the single highest-signal accessibility test. If your site passes this, you’ve already eliminated the majority of showstopper issues.

2. Turn off CSS

Stripping away the visual layer reveals the underlying HTML structure — which is exactly what screen readers and some assistive technologies work from. Modern way to disable CSS:

• Chrome / Edge: Open DevTools (F12), press Ctrl/Cmd+Shift+P, type “Disable CSS” → “Rendering: Disable CSS overrides.” Or install the Web Developer extension for a one-click toggle.
• Firefox: View → Page Style → No Style.
• Safari: Develop → Disable Styles (enable Developer menu first in Settings → Advanced).

What to look for:

• The reading order still makes sense — content flows in a logical top-to-bottom sequence.
• Heading hierarchy is clear — H1, then H2s for major sections, H3s for sub-sections. Screen reader users navigate by headings, so structure matters even when visual design is removed.
• Forms are still usable — every form input has a visible label, buttons are obvious, and error messages appear near the fields they relate to.
• Nothing critical was only communicated by color, position, or styling — those signals are gone without CSS.
• Images have visible alt text where content-relevant, and purely decorative images have empty alt (and therefore don’t appear).

If the site without CSS is a jumbled mess with no clear reading order, screen reader users are having a similarly disorienting experience.

3. Turn off images

Not every user loads images — some are on slow connections, some use assistive tech that ignores them, some explicitly disable image loading. The question: does the page still communicate its purpose?

How to disable images:

• Chrome / Edge: Settings → Privacy and Security → Site settings → Images → Don’t allow sites to show images.
• Firefox: about:config → set permissions.default.image to 2.
• Any browser: Browser extensions like Image Toggle provide one-click on/off.

What to look for:

• Alt text appears in place of each image that carried information. If a key product image has no alt, users see an empty frame.
• Decorative images (backgrounds, dividers) don’t appear as “broken image” placeholders — they use empty alt (alt="") or are CSS backgrounds.
• The page still makes sense. If the image of a step-by-step process was the only explanation, the page fails for image-off users. Add text context.
• Icon-only buttons (“settings”, “menu”, “close”) have accessible names via aria-label or visually-hidden text.

4. Zoom to 200% and 400%

WCAG 1.4.4 (Resize Text) requires content to be usable at 200% zoom without loss of functionality. WCAG 2.2’s new 1.4.10 (Reflow) extends this to 400% zoom without horizontal scrolling on a 320px-wide viewport. Zoom in with Ctrl/Cmd and +:

• Text stays readable (no clipping at edges, no text disappearing under fixed headers).
• Content reflows rather than requiring horizontal scrolling — most modern responsive designs already handle this, but legacy pages often don’t.
• All functionality remains accessible — links, buttons, and forms don’t become hidden behind fixed elements at higher zoom levels.
• Fixed headers don’t eat half the screen at zoom. A 60px header becomes 240px visual weight at 400% zoom, potentially blocking the content below.

The zoom test is fast (< 2 minutes per page) and catches layout issues invisible at normal viewing.

5. Use a screen reader

This is the highest-signal test if you’ve never done it. Every major operating system has a built-in screen reader:

• macOS / iOS: VoiceOver (Cmd+F5 on macOS, triple-click the side button on iPhone).
• Windows: Narrator (Windows+Ctrl+Enter) or the free NVDA.
• Android: TalkBack (Settings → Accessibility → TalkBack).
• Chromebook: ChromeVox (Ctrl+Alt+Z).

All are free. JAWS is the commercial de-facto standard in enterprise environments, but NVDA and VoiceOver are used by majority of screen-reader users globally and will surface most issues.

What to listen for:

• The page announces a logical reading order — title, navigation, main content, footer.
• Headings are announced with their level (“Heading level 2, Why accessibility matters”).
• Images announce either their alt text or are skipped silently (decorative).
• Links describe their destination in isolation. “Click here” and “read more” announced 20 times in a row tells a screen reader user nothing about where each leads.
• Form fields announce their labels when focused. Required fields announce “required.” Errors announce the problem and how to fix it.
• Dynamic content (alerts, modals, loading states) is announced via ARIA live regions, not silently changing.

Twenty minutes with VoiceOver or NVDA on your homepage and one key workflow will teach you more about your site’s accessibility than an hour of reading specs.

6. Test with forced-colors / high-contrast mode

Windows users with low vision often enable Forced Colors Mode (formerly called High Contrast Mode), which overrides site colors with the user’s chosen system palette. Web pages that hard-code colors can lose information in this mode — colored status indicators turn invisible, bordered buttons lose their borders, background images disappear.

How to test:

• Windows 11: Settings → Accessibility → Contrast themes → pick a theme.
• Any browser: DevTools (F12) → Rendering panel → Emulate CSS media feature forced-colors: active.
• Chrome / Edge: DevTools → More Tools → Rendering → forced-colors emulation.

What to look for:

• Icons, buttons, and status indicators remain visible and distinguishable.
• Text and background contrast remains readable — at least 4.5:1 for normal text, 3:1 for large text (WCAG 1.4.3).
• Focus indicators are still visible and use semantic colors (ButtonText, Highlight) rather than hard-coded ones.
• Essential decorative elements (dividers, icons) don’t disappear entirely. Use CSS system-color or CanvasText to ensure they’re styled appropriately in forced-colors mode.

Free browser helpers (worth keeping open)

Three free browser extensions that sit alongside manual testing without being full “accessibility testing tools”:

• axe DevTools (free tier) — Chrome/Firefox extension that runs automated checks on the current page and surfaces issues in a DevTools panel. The free version covers most of the core WCAG rules.
• WAVE — a visual overlay that marks accessibility issues directly on the rendered page. Colorful, immediately understandable, and great for teaching teammates what “accessibility issue” looks like.
• Lighthouse — built into Chrome DevTools. Run an audit, get an accessibility score with specific failing items. Lighthouse’s accessibility checks come from axe-core, so results are reliable.

None replace the manual tests above, but they make some issues visible that otherwise require careful inspection.

Have someone else try it

The single most effective accessibility test: sit someone else down at your site — ideally someone with relevant disability experience or at least someone unfamiliar with the site — and watch them use it. Note where they hesitate, backtrack, or ask “how do I…?” Each of those moments is an accessibility issue, whether or not it fails a specific WCAG criterion.

User testing with people who have disabilities is the gold standard and something paid services offer (Fable, Applause, usertesting.com’s accessibility panels). For a small site, even informal testing with a friend or colleague who uses assistive tech occasionally produces useful feedback.

A simple accessibility testing routine

If doing all six tests on every page is impractical, focus:

• Every page template — run all six tests once per template, not per instance. If your product page template passes, every product page using that template passes.
• Critical paths — homepage, signup, checkout, contact. These are where accessibility failures cost business directly.
• After every major release — keyboard test the new or changed pages, and run Lighthouse against them.
• Quarterly — full manual pass on all critical paths plus spot checks across content.
• Automated checks on every deploy — axe, Pa11y, or similar as part of your CI pipeline. Catches regressions before they ship.

Bottom line

You don’t need a paid tool to do accessibility testing that actually catches problems. Keyboard-only navigation, CSS-off reading, image-off review, zoom testing, screen reader use, and forced-colors mode cover most of the territory automated tools can’t reach — and all six require nothing but a browser and half an hour. Combine them with free tools like axe, WAVE, or Lighthouse for the structural checks, and you’ll surface far more real issues than either approach alone. More importantly, you’ll understand what using your site actually feels like for users who don’t experience the web the way you do. That empathy is what turns accessibility from a compliance checklist into a design practice.