Website Accessibility Testing: A Practical Guide to Making Your Site Work for Everyone

Why I Started Taking Accessibility Seriously

A few years ago, I watched a blind colleague try to use a website I'd helped build. Watching him navigate with a screen reader was eye-opening—and honestly, a bit embarrassing. Links that said "click here" meant nothing out of context. Images had no descriptions. The navigation was a maze.

That experience changed how I think about web development. Accessibility isn't some checkbox for compliance—it's about whether real people can actually use what we build.

And here's the thing: about 15% of the world's population has some form of disability. That's over a billion people. If your website doesn't work for them, you're not just missing out on potential customers—you might also be breaking the law.

The Legal Reality You Can't Ignore

Let me be blunt: web accessibility lawsuits are exploding. In 2023, over 4,000 ADA-related lawsuits were filed against websites in the US alone. And it's not just big corporations getting sued—small businesses and even individual bloggers have been targeted.

The Americans with Disabilities Act applies to websites, even though it was written before the web existed. Courts have consistently ruled that if your business is open to the public, your website needs to be accessible. The European Accessibility Act kicks in this year with similar requirements. Canada, the UK, and Australia all have their own accessibility laws.

The good news? The same fixes that keep you compliant also make your site better for everyone. Accessible sites tend to have better SEO, cleaner code, and improved usability across the board.

Understanding WCAG (Without the Jargon)

WCAG—the Web Content Accessibility Guidelines—is the standard everyone points to for accessibility compliance. It sounds intimidating, but the core ideas are actually pretty intuitive.

Think of WCAG as having four main principles, sometimes called POUR:

Perceivable: Can users actually see or hear your content? This means providing text alternatives for images, captions for videos, and making sure colors have enough contrast.

Operable: Can users actually interact with your site? This means everything should work with a keyboard (not just a mouse), users should have enough time to complete tasks, and nothing should trigger seizures.

Understandable: Does your site make sense? This means using clear language, making navigation consistent, and helping users avoid and fix mistakes.

Robust: Does your site work with different technologies? This means using proper HTML, testing with different browsers, and ensuring compatibility with assistive technologies like screen readers.

Most legal requirements target "Level AA" compliance, which is the middle ground—not the bare minimum, but not the most stringent either. That's what you should aim for.

The Most Common Accessibility Problems (And How to Fix Them)

After auditing hundreds of websites, I've noticed the same issues come up again and again. Fix these, and you'll solve probably 80% of accessibility problems.

Images Without Alt Text

This is the single most common accessibility failure, and it's one of the easiest to fix.

When a screen reader encounters an image without alt text, it either skips it entirely or reads the filename—which might be something helpful like "IMG_3847.jpg." Not exactly useful.

The fix is simple: add descriptive alt text to every meaningful image. Describe what's in the image and why it matters. "Company team photo showing 12 employees standing in front of office building" is much more useful than "team" or "photo."

For purely decorative images—like background patterns or design elements—use an empty alt attribute (alt=""). This tells screen readers to skip the image entirely.

One mistake I see often: starting alt text with "Image of" or "Picture of." Screen readers already announce that it's an image, so you're just wasting words.

Low Color Contrast

I once reviewed a site with light gray text on a white background. The designer said it looked "clean and modern." It was also nearly impossible to read for anyone with even mild vision impairment—or honestly, anyone trying to use the site in bright sunlight.

WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. That sounds technical, but tools like WebAIM's Contrast Checker make it easy to verify.

The usual culprits are light gray text, thin fonts, and colored text on colored backgrounds. When in doubt, make text darker and backgrounds lighter. Your users' eyes will thank you.

Missing or Broken Keyboard Navigation

Try this right now: put your mouse away and navigate your own website using only the Tab key, Enter, and arrow keys. Can you access everything? Can you see where your focus is at all times?

Many people can't use a mouse—whether due to motor disabilities, injuries, or personal preference. If your site doesn't work with a keyboard, it doesn't work for them.

The most common problems I find:

No visible focus indicator. When you Tab through a page, you need to see which element is currently selected. Many designers remove the default browser outline because it "looks ugly." Don't do that—or if you must, replace it with something equally visible.

Custom elements that aren't keyboard accessible. If you build a dropdown menu with divs instead of proper button and link elements, it probably won't work with a keyboard. Use semantic HTML elements, or add the necessary ARIA attributes and keyboard event handlers.

Focus traps. Modal dialogs are notorious for this. Users Tab into a modal and can't Tab out. Always provide a clear way to close modals with the keyboard, and return focus to the triggering element when the modal closes.

Forms That Don't Make Sense

Forms are where accessibility really matters, because forms are often where the important stuff happens—signing up, checking out, contacting support.

Every input field needs a label. Not a placeholder—a real label that stays visible even after users start typing. Placeholders disappear, leaving users wondering what they were supposed to enter.

Group related fields together and give each group a clear heading. If you have a shipping address section and a billing address section, make that structure clear both visually and in the code.

When users make mistakes, tell them clearly what went wrong and how to fix it. "Invalid input" is useless. "Please enter a valid email address (example: name@domain.com)" actually helps.

Links That Say Nothing

"Click here." "Read more." "Learn more."

These links are everywhere, and they're accessibility nightmares. Screen reader users often navigate by pulling up a list of all links on a page. Imagine hearing "click here, click here, click here, read more, learn more" with no context about where any of those links go.

The fix is simple: make your link text descriptive. Instead of "Click here to download our annual report," just say "Download our 2024 Annual Report (PDF, 2.5MB)."

Videos Without Captions

If you have video content without captions, you're excluding deaf and hard-of-hearing users entirely. You're also excluding anyone watching in a quiet environment or a noisy one, anyone whose first language isn't the one being spoken, and anyone who just prefers to read.

YouTube and other platforms can auto-generate captions, but they're often hilariously inaccurate. Take the time to review and correct them, or pay for professional captioning. Your content is worth it.

How to Actually Test for Accessibility

Automated tools can find some problems, but they'll miss a lot. Real accessibility testing requires a combination of automated scans, manual testing, and (ideally) testing with actual users who have disabilities.

Start With Automated Tools

Run your site through Lighthouse (built into Chrome DevTools), the WAVE browser extension, or a tool like BulkAudit that can test multiple pages at once. These will catch obvious issues like missing alt text, low contrast, and missing form labels.

Just know that automated tools only catch about 30-40% of accessibility issues. A passing score doesn't mean your site is accessible—it means you've cleared the first hurdle.

The Keyboard Test

Unplug your mouse. Seriously, unplug it or move it out of reach. Then try to do everything on your site using only the keyboard.

Can you navigate to every page? Can you open and close menus? Can you fill out forms and submit them? Can you always see where you are on the page?

This simple test catches an enormous number of issues. If you can't do something without a mouse, users who rely on keyboards can't either.

Try a Screen Reader

This is uncomfortable at first, but incredibly valuable. Turn on VoiceOver (Mac) or NVDA (Windows, free) and try to use your site with your eyes closed.

Does the page structure make sense when read aloud? Do images have descriptions? Do links and buttons clearly indicate what they do? Can you navigate by headings to jump to different sections?

Even 30 minutes with a screen reader will teach you more about accessibility than reading articles about it.

Check Your Color Contrast

Use a contrast checker tool to verify that all text meets the 4.5:1 ratio requirement. Pay special attention to:

Text on colored backgrounds

Placeholder text in form fields

Links (which need to be distinguishable from surrounding text)

Focus indicators and hover states

Zoom to 200%

Use your browser's zoom function to scale the page to 200%. Does everything still work? Can you read all the content? Does anything overlap or get cut off?

Many users with low vision use browser zoom rather than screen readers. If your site breaks at 200% zoom, you've got work to do.

Building Accessibility Into Your Process

The best time to think about accessibility is at the beginning of a project, not when you're scrambling before launch (or worse, after receiving a demand letter).

When designing, consider contrast and readability from the start. When developing, use semantic HTML elements. When writing content, create descriptive link text and alt text. When testing, include accessibility in your QA checklist.

Some specific suggestions:

Add automated accessibility testing to your CI/CD pipeline using tools like axe-core or pa11y. This catches regressions before they ship.

Run a quick manual keyboard test before any release. It takes five minutes and catches issues automated tools miss.

Conduct periodic comprehensive audits, especially after major redesigns. Use tools like BulkAudit to scan multiple pages efficiently.

If budget allows, hire disabled users to test your site. There's no substitute for feedback from people who actually use assistive technologies daily.

The Bottom Line

Accessibility isn't about checking boxes for compliance (though that matters). It's about building websites that work for actual humans, regardless of how they access the web.

The good news is that accessible sites are usually better sites, period. Clear navigation helps everyone. Good contrast helps everyone. Descriptive links help everyone. By designing for accessibility, you're designing for usability.

Start where you are. Run your site through BulkAudit or Lighthouse to identify the biggest issues. Fix the most common problems first: alt text, contrast, keyboard navigation, form labels. Then keep iterating.

Your future users—all of them—will be glad you did.