Web accessibility for small businesses

Many moons ago, I worked at an agency. Back then, the website development project was the hook. What we were really after was the monthly marketing and SEO engagement. Our websites were (initially, we got better at this) formulaic with no consideration for accessibility in our workflows.

I could excuse this by saying, “Well, that was almost 10 years ago! So much has changed!”

But, web accessibility isn’t new:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, 1997, on launching the Web Accessibility Initiative (WAI)

Has the profitable, commercial business of producing web product drifted so far from that noble venture of creating universal access to information? Or, are people doomed by their own peopley-ness, moved to act only when our individual needs and interests are affected?

When we make something inaccessible, it’s rarely because we set out to exclude anyone. It’s usually because we didn’t think about it, because our own experience of the web felt like everyone’s experience. This complacency is a real problem. Not questioning our own internalized bias and assumptions, not considering experiences different from our own is harmful, whether or not that is our intent. People who are shut out by an inaccessible website don’t experience what we meant to do, they experience what we built.

Digital accessibility is a critical knowledge gap for business owners and (still) a lot of developers and designers. Whether you decide to work with a developer or DIY your website, you need to know what to ask for.

What is web accessibility?

When I speak to new or prospective clients about web accessibility, most of them aren’t sure what that means or how it applies to their website project. In a recent conversation, a new client who had just launched a redesigned website, said simply: “Our previous developer never mentioned this.”

Most of us associate the Americans with Disabilities Act (ADA) with physical spaces like ramps, automatic doors, accessible parking. Making digital spaces accessible is the same idea; websites should not create barriers for individuals with disabilities.

Poorly designed websites can create unnecessary barriers for people with disabilities, just as poorly designed buildings prevent some from entering.

Online Barriers, Archive, ADA.gov

An accessible website works for people with a range of disabilities: someone navigating by keyboard instead of a mouse, a blind user relying on a screen reader to read page content aloud, a person with low vision who needs high contrast or larger text, or someone with a cognitive disability who benefits from plain language and consistent navigation.

Web Content Accessibility Guidelines (WCAG), is built around four principles known as POUR: content must be Perceivable, Operable, Understandable, and Robust.

1. Perceivable — including text alternatives for images, captions for video, and sufficient color contrast.
2. Operable — navigable by keyboard, not dependent on a mouse or touch gesture.
3. Understandable — clear language, consistent structure, forms that tell you what went wrong.
4. Robust — built in a way that works reliably across different browsers and assistive technologies.

ADA compliance vs. WCAG conformance

These terms get used interchangeably, but they mean different things. The Americans with Disabilities Act (ADA) is a civil rights law that prohibits discrimination against people with disabilities and guarantees equal access to employment, public spaces, services, and information. It includes your entire business: your website, your PDFs, your email newsletters, your social media, your physical location. WCAG conformance is a technical standard applied to your website, or other digital materials, defining testable criteria for what makes web content accessible.

While ADA doesn’t specify WCAG as an enforceable standard, U.S. Courts and the Department of Justice consistently use WCAG when evaluating whether a website meets accessibility expectations. The current minimum standard is WCAG 2.1, level AA. You don’t need to memorize the guidelines, but you should be aware that this is the benchmark your website needs to meet.

But, my audience isn’t disabled

More than 1 in 4 adults (28.7 percent) in the United States have some type of disability¹.

From a business perspective, can you afford to ignore almost 29% of the people you want to reach? And that’s before accounting for situational or temporary disabilities. A broken wrist, a migraine, age-related vision changes, a noisy environment where someone can’t play audio — these are situations that put anyone in the position of needing an accessible experience.

Simply because an individual is a nonuser of accessible elements today does not mean that he or she will remain so tomorrow. In any given year, there is some probability that an individual will develop a disability (either temporary or permanent) that will necessitate use of these features.

Alternate Scenarios, Title III Regulations Supplementary Information

Web accessibility isn’t creating for a niche group of people, it is including your whole audience.

I know accessibility matters, but do I “have” to do this?

If you run a business that’s open to the public — which includes almost any business with a website — the answer is, “Yes, you have to do this”. Title III of the ADA applies to private businesses as places of public accommodation, and courts have consistently interpreted that to include websites.

State and local governments have their own obligation under a separate section, Title II, and the Department of Justice issued a final rule in 2024 codifying WCAG 2.1 AA as the legal standard for government websites. Those compliance deadlines were extended in April 2026 — but some people argue that deadline is irrelevant. Your inaccessible website is excluding people today.

Your website is part of your business, and your business has obligations under the ADA. There is no size exemption under Title III.

About lawsuits

Businesses can get sued over web accessibility. It happens more than you might realize, increasing 27% in 2025 from the previous year.

The targets aren’t always large companies. Law firms, medical practices, restaurants, hotels, retail businesses, and professional services firms of all sizes have been named in ADA website cases.

What tends to draw attention:

• No accessibility statement. An accessibility statement signals that you’re aware of your obligations and have a process for addressing them. Its absence can signal the opposite.
• Accessibility overlays. A site running an overlay signals that the underlying code hasn’t been addressed. Some users find overlays actively disruptive to their assistive technology, which creates additional grounds for complaint.
• A broken or unusable experience for screen reader users. If a site is functionally unusable — no way to navigate, forms and tasks that can’t be completed.
• Ignoring accommodation requests. If someone reaches out to tell you they can’t use your site, and you do nothing, that creates additional legal risk.

If you’re ever in this position, documentation can help:

Your goal is demonstrable, ongoing effort. Courts and plaintiffs’ attorneys look for evidence of good faith.

• Document your work. Keep records of what accessibility decisions were made during development, any third-party audits you’ve commissioned, and any accommodation requests you’ve received and how you responded.
• Have an accessibility statement on your site that describes your standards, your known limitations, and how someone can request an accommodation.
• If you’ve had work done since launch like fixes, updates, improvements, make a note of that too.

A formal third-party accessibility audit, conducted by a qualified evaluator, carries more legal weight than a developer’s self-assessment. It’s not cheap², but if your site serves a large audience or you operate in a higher-risk category (healthcare, government-adjacent work, financial services), it’s worth considering.

Who is responsible for web accessibility, you or your developer?

Yeah, there’s a lot of people that ask me … ‘Should accessibility be its own thing? Or should it be a part of everybody’s job and something that everybody does?’ And they ask it like it’s an ‘or’ question; like it has to be one or the other. But it really should be both. Right? Like, accessibility should be part of everything, because it’s part of everybody’s job.

Derek Featherstone, UX Podcast, “State of Accessibility“

Your developer is responsible for building an accessible website. Accessibility involves technical decisions made throughout design and development, and a competent designer or developer should be treating it as an integral part of the work, not something to add at the end of a project.

You, as the business owner, are responsible for the content you add after launch as well as for the website overall. If you upload a PDF that isn’t accessible, write a page with no meaningful heading structure, or post an image without describing it, that’s on you. More importantly: if someone with a disability can’t use your website, you are the one who can be sued³.

If you have staff who add content to your site, they share that responsibility too. Training the people who maintain your content is part of maintaining an accessible website.

If you’re working with a developer, here’s what to ask:

• Are you building to WCAG 2.1 AA standards?
• Will the site work for someone navigating by keyboard only?
• Are you using semantic HTML; proper heading structure, labeled form fields, descriptive link text?
• Will you do any accessibility testing before launch, and if so, how?
• Can you add an accessibility statement to the site?

A developer who can’t answer these questions clearly is a developer who isn’t building with web accessibility in mind (more about what to ask your developer in my Website Owner’s Missing Manual post).

Progress, not perfection

Say you have a website. Conducting an accessibility audit will produce a list of issues, an explanation of the failure, and recommendations for remediation.

Types of accessibility audits

• Automated scanning – Automated tools can crawl your site and flag common issues. It’s fast, it’s a useful starting point, and it catches roughly 30 percent of accessibility problems. The other 70 percent require human judgment.
• Manual evaluation – A trained evaluator navigates your site using a keyboard and screen reader software, reviews your code, and identifies structural problems that automated tools can’t detect.
• Evaluation by disabled accessibility professionals – Professional expertise combined with the lived experience of navigating the web with assistive technology every day.

The audit report also shows that you engaged a qualified professional, identified issues in good faith, and had a remediation plan. If you ever receive a demand letter, this can be very helpful documentation.

Remediation: after the audit

An audit tells you what’s failed the standard. Remediation is making changes that remove barriers and allow you to meet the WCAG success criteria.

Remediation work should be prioritized because not every issue is equally important. A missing form label that prevents a screen reader user from completing a contact form is more urgent than a color contrast ratio that’s slightly below threshold on a decorative element.

After remediation, retest.

Remediation isn’t a finish line. Websites change — you add pages, update content, install new plugins. Regular accessibility testing should be part of how you maintain your site, the same way you update software, check for broken links, or monitor your search performance.

Caveat: no website is 100% accessible

No evaluation process, and no website, can be perfectly accessible for every person in every situation. Disability is not a single, uniform experience. Accessibility is ongoing work. Build with accessibility in mind, test what you can, respond to feedback, and keep improving.

Do we need a law to do the right thing?

The Americans With Disabilities Act was signed into law in 1990 after more than a century of activism by people with disabilities who were excluded from spaces built without them in mind. The law exists because too many people and institutions needed to be required to care.

Web accessibility is a founding principle of the internet, we should treat it as an essential requirement in our work designing and developing websites for people. Part of this work as developers and content creators is to keep learning, expanding our understanding of our roles, and doing what we can do to make the world (and the web) a little better.

1. CDC Data Shows Over 70 Million U.S. Adults Reported Having a Disability ↩︎
2. You can also claim the Disabled Access Credit on your business taxes for eligible expenses. ↩︎
3. For any developers reading this, it’s also worth knowing that agencies have been named as co-defendants in accessibility lawsuits alongside the businesses they built for. Building accessible websites isn’t just good practice, it’s professional protection. ↩︎