Lazy Dev Guide: Avoid Accessibility Suits

Look, I'm not going to tell you that you should care about accessibility because it's the right thing to do. You probably already know that. I'm going to tell you the minimum viable set of things to fix so that a plaintiff's attorney doesn't have a trivially easy case against you. Pragmatism over idealism. Let's go.

First: web accessibility lawsuits are real, have been increasing in recent years, and are reportedly targeting smaller companies more frequently. Many courts have found that the ADA applies to websites, though legal interpretations continue to evolve. And the plaintiffs' bar has gotten very good at finding sites with obvious, fixable violations and filing demand letters. This is a growing area of litigation.

The good news is that most lawsuits target the obvious stuff. Fix the obvious stuff and you're no longer the path of least resistance. Here's the obvious stuff.

Step 1: Run a Scan (30 Seconds, Free)

Install SCOUTb2, open your homepage, click scan. Do this before you do anything else. You need to know what you're dealing with.

The scan runs 26 accessibility checks and flags common issues it detects, along with their locations on the page. It takes less than a minute. I'm including this as a step because "run the audit first" is apparently not obvious to everyone, given how many sites are out there with fixable issues that nobody has ever even looked for.

Once you have your results, you'll probably see a list. Some of it will feel overwhelming. Ignore that feeling and look for the specific issue categories I'm about to describe. Those are the ones to prioritize.

Step 2: Fix Alt Text (Biggest Bang for Buck)

Missing alt text on images is widely reported as one of the most commonly cited accessibility violations in legal complaints. It's also one of the easiest things to fix. Every image that conveys information needs an alt attribute that describes what the image shows.

Some practical rules:

• Decorative images (dividers, backgrounds, purely visual flourishes) should have alt="" (empty, not missing). This tells screen readers to skip it.
• Content images need descriptive alt text. "Photo of team" is bad. "Five-person software engineering team at the SCOUTb2 company retreat in Austin" is good.
• Linked images (like a logo that links to the homepage) need alt text that describes the link destination. "SCOUTb2 homepage" not "logo".
• Functional images (buttons with no text, just an icon) need alt text that describes the function. "Search" not "magnifying glass icon".

Your CMS probably has an alt text field for every image. Fill them in. If you have hundreds of images with no alt text, prioritize the ones in navigation, key product imagery, and anything above the fold. Start there and work your way down.

Step 3: Check Color Contrast (79% of Sites Fail This)

WCAG requires a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text (18pt or 14pt bold). Most sites don't hit this for at least some text. Common offenders:

• Gray placeholder text in form fields
• Light-colored navigation links over a medium-colored background
• White text over a medium-saturation colored button
• Any text in your "subtle" or "muted" color from your design system

SCOUTb2 flags contrast failures with the specific elements and their actual contrast ratios. Take that list to your designer (or to yourself, if you're the designer too). The fix is usually just darkening the text color or lightening the background. In most design systems, you're swapping one color token for another.

I know "79% of sites fail this" sounds like I made it up, but that figure has been reported in annual accessibility surveys of the top million websites (such as the WebAIM Million study). Color contrast is the most pervasive WCAG failure on the web. Fixing it puts you ahead of the majority of the internet by default.

Step 4: Make Your Forms Keyboard-Accessible

Forms are where a lot of accessibility lawsuits focus because they're where users try to do things: purchase, sign up, contact, submit. If your form doesn't work for keyboard users, that's a concrete barrier to access.

The checklist for keyboard-accessible forms:

• Every input has a proper <label> element connected with a for attribute matching the input's id. Placeholder text is not a label.
• You can tab through every field in a logical order without getting stuck.
• Error messages are announced to screen readers (use aria-live or role="alert").
• Required fields are marked programmatically (the required attribute, not just a visual asterisk).
• Custom dropdowns, date pickers, and multi-selects are actually keyboard-operable. If you built a custom select component, test it with just the keyboard. If you can't operate it without a mouse, neither can keyboard users.

If you have any "fancy" form components from a UI kit, check their accessibility docs. Some UI libraries are great about this. Others are a nightmare. Know which one you're using.

Step 5: Add Skip Links (Takes 10 Minutes, Nobody Does It)

A skip link is a link that appears at the very top of the page, usually invisible until focused, that lets users jump directly to the main content. The purpose is to let keyboard users skip past your navigation on every single page load without tabbing through 30 menu items each time.

Here's essentially all the code you need:

<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- later in your HTML -->
<main id="main-content">...</main>

And the CSS:

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

That's it. The link is invisible unless someone tabs to it (at which point it appears in the top-left corner), and clicking it skips to the main content. WCAG 2.4.1 requires this for pages with repeated navigation. Almost nobody implements it. Now you will. You're already better than 90% of the web.

The Honest Truth About What This Gets You

Following these five steps will not make your site fully WCAG 2.2 AA compliant. Full compliance requires an audit, remediation work, and ongoing testing, including with real assistive technology users. It's a real commitment.

What these steps will do is eliminate the most commonly cited, most easily documented, and most legally actionable issues. Alt text, color contrast, form accessibility, and skip links are among the most frequently cited issues in accessibility lawsuits. Fixing them makes your site meaningfully more usable for people with disabilities, which is the actual point, and may help reduce your exposure to the types of demand letters that target easily identifiable violations.

Start by running a free scan with SCOUTb2 to see exactly where you stand. If you have a multi-page site and want to run these checks across all your pages without clicking through each one manually, SCOUTb2 Pro can crawl up to 10,000 pages and flag issues across your whole site at once.

Is this legal advice? Absolutely not. Talk to an actual lawyer about your actual legal risk. But as a fellow developer who has had to explain accessibility issues to angry stakeholders more times than I care to count, I can tell you that the five steps above are where I start every time. They're fast, they're high-impact, and they're hard to argue with when someone asks what you've done about accessibility compliance.

Now go fix your alt text. I'll be here.

Disclaimer: This article is for informational purposes only and does not constitute legal, professional, or compliance advice. Nothing in this post should be interpreted as legal guidance or a guarantee of reduced legal risk. Consult a qualified attorney for advice on your specific situation. SCOUTb2 is an automated scanning tool that helps identify common issues but does not guarantee full compliance with any standard or regulation.