The 5 Most Common ADA Violations on Small Business Websites
We have scanned thousands of small business websites for ADA compliance. Dentists, restaurants, law firms, salons, chiropractors, auto shops — across every industry and every website platform. And after running all those scans, a clear pattern has emerged: the same five accessibility violations show up on nearly every site.
These are not obscure, edge-case issues. They are fundamental problems that affect real people — the 61 million Americans living with disabilities who rely on assistive technology to browse the web. They are also the exact issues that plaintiff's attorneys look for when filing ADA website lawsuits.
The good news: every one of these violations is straightforward to fix. You do not need to rebuild your website. In most cases, a developer can resolve all five in a single afternoon. Here is what to look for and exactly how to fix each one.
1. Missing Alt Text on Images
What it is
Every image on a webpage needs an alt attribute — a short text description that tells screen readers what the image shows. When an image has no alt text, a screen reader either skips it entirely or announces the file name, which sounds something like "image slash DSC underscore 4072 dot jpeg." Neither outcome is useful.
This is the single most common ADA violation we find. It appears on roughly four out of five small business websites, often on dozens of images per page.
Why it matters: A blind user visiting your website has no idea what your images show. That staff photo on your About page? They do not know it exists. The hero image of your storefront? Invisible. Product photos on an e-commerce site? Completely inaccessible. For a business that relies on visual content to build trust and drive conversions, this is a significant portion of your website that an entire population segment simply cannot access.
What it looks like in code:
<!-- Bad: no alt attribute at all -->
<img src="team-photo.jpg">
<!-- Also bad: empty alt on a meaningful image -->
<img src="team-photo.jpg" alt="">
<!-- Good: descriptive alt text -->
<img src="team-photo.jpg" alt="Our dental team standing in the lobby of our Portland office">
<!-- Good: decorative image gets empty alt -->
<img src="blue-divider-line.png" alt="">
The fix: Add descriptive alt text to every meaningful image. Describe what the image shows in a short, specific phrase — not "image" or "photo," but what is actually in the picture. For purely decorative images (divider lines, background textures), use alt="" so screen readers skip them. If you use a CMS like WordPress or Squarespace, there is usually an "alt text" field in the image editor — fill it in for every image.
2. Insufficient Color Contrast
What it is
Text must have enough visual contrast against its background to be readable. WCAG requires a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text (18px bold or 24px regular). When text falls below these thresholds, it becomes difficult or impossible to read for people with low vision, color blindness, or anyone viewing a screen in bright sunlight.
Why it matters: Roughly 300 million people worldwide have some form of color vision deficiency. Millions more have low vision that makes faint text unreadable. But this is not just a disability issue — anyone who has tried to read light gray text on a white background on a phone screen outdoors knows the frustration. Poor contrast is a usability problem for everyone.
Common offenders:
- Light gray text on a white background (the most common failure we see)
- Placeholder text in form fields — nearly always fails contrast
- White text on light-colored hero images without a background overlay
- Footer links in a medium gray on a dark background
- Small text in cookie banners, copyright notices, and disclaimers
What it looks like in code:
<!-- Bad: light gray on white = 2.6:1 ratio (fails) -->
<p style="color: #999999;">Our office hours are...</p>
<!-- Good: darker gray on white = 7.0:1 ratio (passes) -->
<p style="color: #595959;">Our office hours are...</p>
<!-- Bad: placeholder text almost always fails -->
<input placeholder="Enter your email" style="color: #aaa;">
<!-- Good: use a visible label instead of relying on placeholder -->
<label for="email">Email address</label>
<input id="email" type="email">
The fix: Use a contrast checker tool — WebAIM's Contrast Checker is the standard. Plug in your text color and background color, and it will tell you whether you pass WCAG AA. As a rule of thumb, bump your text colors darker. Swap #999 for #595959 or darker. Avoid relying on placeholder text as the only label for form fields — use a visible <label> element instead.
3. Unlabeled Form Fields
What it is
Form fields — text inputs, dropdowns, checkboxes, radio buttons — need to be programmatically associated with a label that describes what information to enter. Without a label, a screen reader announces "edit text" or "combo box" with zero context. The user has no idea whether they are supposed to type their name, email address, phone number, or credit card number.
Why it matters: Forms are where conversions happen. Contact forms, appointment bookings, newsletter signups, checkout pages — if a user cannot fill out your forms, they cannot do business with you. For a screen reader user encountering an unlabeled form, every field is a guessing game. They might tab through five fields hearing "edit text, edit text, edit text, edit text, edit text" with no indication of what goes where.
What it looks like in code:
<!-- Bad: no label associated with the input -->
<input type="text" name="email" placeholder="Email address">
<!-- Bad: label exists but isn't linked to the input -->
<label>Email</label>
<input type="text" name="email">
<!-- Good: label linked with matching for/id -->
<label for="email">Email address</label>
<input type="text" id="email" name="email">
<!-- Also good: aria-label for icon-only search fields -->
<input type="search" aria-label="Search our website">
The fix: Every form field needs a <label> element with a for attribute that matches the field's id. This creates a programmatic connection that screen readers can announce. For fields where a visible label does not fit the design (like a search bar with only a magnifying glass icon), use aria-label to provide an invisible label. And remember: placeholder text is not a substitute for a label — placeholders disappear when the user starts typing and are not reliably announced by all screen readers.
4. Missing Keyboard Navigation
What it is
Every interactive element on a webpage — links, buttons, form fields, menus, tabs, modals — must be fully operable using only a keyboard. Users must be able to reach every element with the Tab key, activate it with Enter or Space, and see a visible focus indicator showing which element is currently selected. When keyboard access is broken, an entire category of users is locked out.
Why it matters: Not everyone uses a mouse. People with motor disabilities often use keyboard-only navigation, switch devices, or voice control — all of which rely on keyboard accessibility under the hood. Screen reader users navigate exclusively by keyboard. Even power users without disabilities frequently tab through forms and use keyboard shortcuts. When your dropdown menu only opens on mouse hover, or your "Book Now" button is a <div> that only responds to clicks, these users simply cannot interact with your site.
What it looks like in code:
<!-- Bad: div with click handler (not keyboard accessible) -->
<div class="btn" onclick="submitForm()">Submit</div>
<!-- Good: use a real button element -->
<button type="submit">Submit</button>
<!-- Bad: focus outline removed globally -->
*:focus { outline: none; }
<!-- Good: custom focus style that's clearly visible -->
*:focus-visible { outline: 3px solid #2563eb; outline-offset: 2px; }
The fix: Use native HTML elements whenever possible. A <button> is keyboard-accessible by default — a styled <div> is not. If you must use a non-standard element, add tabindex="0" to make it focusable and add keyboard event handlers for Enter and Space. Never remove focus outlines globally with outline: none. Instead, use :focus-visible to show focus indicators only when the user is navigating by keyboard — this gives you clean mouse interactions and accessible keyboard navigation at the same time.
Quick test: Put your mouse away and try to navigate your entire website using only the Tab key, Enter, and Escape. Can you reach every link, button, and form field? Can you open and close menus? Can you always see which element is focused? If the answer to any of these is no, you have a keyboard accessibility problem.
5. Improper Heading Structure
What it is
Headings (H1 through H6) are not just visual formatting — they create a document outline that screen readers use for navigation. Sighted users can scan a page visually and jump to the section they want. Screen reader users do the same thing by navigating through headings. When headings are skipped, duplicated, or used purely for visual styling, this navigation system breaks.
Why it matters: Screen reader users frequently navigate by headings — it is one of the primary ways they scan and understand a page. A user might press "H" to jump through each heading, building a mental map of the page structure. If your page jumps from H1 to H4, or uses H3 for a tagline just because you liked the font size, or has no H1 at all, the page becomes disorienting and difficult to navigate. It is the equivalent of ripping the table of contents out of a book and scrambling the page numbers.
What it looks like in code:
<!-- Bad: skipped heading levels, multiple H1s -->
<h1>Welcome to Our Practice</h1>
<h1>Best Dentist in Portland</h1>
<h4>Our Services</h4> <!-- skipped H2 and H3 -->
<h2>Contact Us</h2>
<!-- Good: one H1, sequential hierarchy -->
<h1>Welcome to Our Practice</h1>
<h2>Our Services</h2>
<h3>General Dentistry</h3>
<h3>Cosmetic Dentistry</h3>
<h2>Contact Us</h2>
The fix: Every page should have exactly one <h1> that describes the page's main topic. After that, use <h2> for major sections, <h3> for subsections within those, and so on. Never skip a level — do not jump from <h2> to <h4>. And never use a heading tag just because you want bigger or bolder text — use CSS for visual styling and reserve heading tags for document structure. If you need text that looks like a heading but is not a section title, use a <p> or <span> with appropriate CSS classes.
These 5 Issues Get You 80% of the Way There
Across all the websites we have scanned, these five violations account for the vast majority of issues found. Fixing them will not make your site 100% WCAG compliant — there are 50 success criteria in WCAG 2.1 Level AA, and some require nuanced judgment — but it will eliminate the most common, most visible, and most legally actionable problems.
Think of it as the 80/20 rule applied to accessibility. These five fixes require relatively modest effort, but they deliver outsized impact for users with disabilities and significantly reduce your legal exposure. Most of them can be addressed in a few hours of developer time.
For context, here is where each violation falls in terms of legal risk:
- Missing alt text — Cited in the majority of ADA website lawsuits. It is the easiest violation to detect and the hardest to defend.
- Color contrast — Frequently cited, especially on e-commerce sites. Courts have consistently upheld contrast requirements.
- Unlabeled form fields — High risk for any site that collects information. If a user cannot complete your contact form, that is a clear barrier.
- Keyboard navigation — A core accessibility requirement. Total keyboard inaccessibility is one of the strongest claims a plaintiff can make.
- Heading structure — Lower individual legal risk, but it compounds with other issues and signals a general lack of accessibility consideration.
Start with alt text and labels. If you can only tackle two things today, add alt text to your images and labels to your form fields. These are the highest-impact, lowest-effort fixes, and they address the two violations most commonly cited in ADA lawsuits.
See which violations your site has
Our free scan checks your website for these violations and more in about 60 seconds. No signup required.
Check Free in 60 SecondsRelated Resources
- ADA Website Compliance: What Every Small Business Owner Needs to Know in 2026
- ADA Website Audit: How to Test Your Site for Accessibility Issues
- ADA Compliance Audit: What It Covers, What It Costs, and How to Get One
- What's in an Accessibility Audit Report? A Complete Breakdown
About ADA Audit Report
ADA Audit Report scans websites for ADA and WCAG 2.1 compliance using axe-core, the same accessibility engine trusted by Microsoft, Google, and U.S. government agencies. We provide clear, actionable reports with before-and-after code examples that your developer can implement immediately. Our full reports cost $49 — no subscriptions, no overlays, no ongoing fees.