ADA Website Compliance for Small Business: Our Step-by-Step Accessibility Guide

We recently realized that we needed to prioritize website accessibility and make sure our site was truly usable by everyone. While researching ADA standards for accessibility, we discovered that making websites accessible is essential for serving the 16% of the global population that has some form of disability.

We’ll be honest. Until this point we had not given website accessibility the attention it deserves. Like many small businesses, we’d focused on making our site look good and function well for most users, but we hadn’t thought deeply enough about accessibility. We knew it was important, but it felt overwhelming and we weren’t sure where to start.

Time to take action – Our Website Accessibility Game Plan

At this point, it was obvious we needed to get serious about accessibility on our site. We’re not accessibility experts (and don’t pretend to be), but we wanted to make sure our website was genuinely usable for everyone. Here’s what we did over the course of a few days:

Step 1: Understanding the Web Content Accessibility Standards

We set out to understand what ‘accessible’ actually means in practice for a website. It turns out, the recognised benchmark is the Web Content Accessibility Guidelines (WCAG) 2.2, developed by the World Wide Web Consortium. These guidelines break accessibility down into levels: A, AA, and AAA.

We quickly discovered that Level AA is the standard most laws and lawsuits refer to – and it’s the practical target for almost all commercial websites. Level AAA is technically the most strict, but most experts (including those who write the guidelines) agree it’s unworkable for typical sites. In short, AA is the goal you’re legally expected to aim for, and it’s realistically achievable for nearly everyone.

The guidelines are built around four main principles:

• Perceivable – Information must be presentable in ways users can perceive
• Operable – Interface components must be operable by all users
• Understandable – Information and UI operation must be understandable
• Robust – Content must work with various assistive technologies

Step 2: Documenting the Process in Our Company Wiki

To make sure our approach would be consistent and easy to follow—both now and for anyone dealing with this in future—we drafted the exact steps into our company wiki. This meant we had a reference to hand while working through the process, and it also provided clear evidence of our intent and actions around accessibility.

Step 3: Evaluating Website Accessibility Using WAVE

Before we could fix anything, we needed a way to actually spot accessibility issues on our site. There are loads of tools out there, but we wanted something reliable, privacy-friendly, and easy for non-developers to use.

WAVE stood out for several reasons:

• Non-profit credibility: Developed by WebAIM at Utah State University (academic institution)
• Track record: Operating since 2001, used to evaluate millions of web pages
• Privacy-first: Browser extension runs locally—zero data transmission
• Transparency: Open about limitations—doesn’t claim to “certify” accessibility
• Educational focus: Built for learning, not commercial gain
• Free service: No commercial agenda behind the tool

We installed the WAVE (Web Accessibility Evaluation Tool) Chrome extension. It’s not perfect – no automated tool can catch everything – but it gives you a good starting point by identifying obvious problems like missing alt text, poor colour contrast, and structural issues.

The great thing about WAVE is that it shows you exactly where problems are on your page by injecting little icons and indicators. You can see at a glance what needs attention, which made the whole process feel much less overwhelming than we’d expected.

Step 3: Create an Accessibility Spreadsheet for Website Audits and our records

We created a simple spreadsheet to track all the warnings and errors WAVE flagged. For each issue, we noted:

• What the problem was
• Which page it was on
• The suggested fix
• Whether we’d addressed it

This helped us stay organized and ensure we didn’t miss anything and it made sense to be documenting everything.

Step 4: Fixing Our Website’s Accessibility Issues

Most of the problems we found were pretty straightforward to fix. We got lucky with a couple of early wins. Some of our first errors were in the header and footer, so fixing those cleared up multiple problems across the entire site at once.

WAVE is excellent at flagging issues, but it wasn’t always immediately clear where the problem was located. Sometimes an error might not be visible on your screen at that moment. It could be in a mobile layout version or hidden element that only appears under certain conditions.

For example, our mobile hamburger menu image was missing alt text, but we only located the exact problem when we used WAVE’s ‘Styles off‘ toggle. This feature strips away all the CSS styling, showing you the page as it appears in the underlying code structure. When we turned styles off, the hidden hamburger menu became visible in the linearized content, making it easy to identify and fix the missing alt text.

This ‘no styles’ view is actually how screen readers experience your content. In the order it appears in the code, without any visual styling. It’s incredibly useful for spotting issues that might be hiding in responsive layouts or elements that are only visible under certain conditions.

Linked image missing alt text on images

This error specifically relates to images that are being used as clickable buttons or links. When an image functions as a link, it needs descriptive alt text to tell screen reader users where that link will take them.

We’re generally good at adding alt text to our regular images, but we had missed a few cases where images were serving as navigation elements. For example, we had a logo in the footer that links back to the top of the page, but it lacked proper alt text to explain its function.

The main culprit was our blog homepage, which automatically generates thumbnail images for each blog post. By default, these thumbnails didn’t include alt text when used as links to the full articles. This meant screen reader users would encounter something like ‘link, image’ with no indication of what the blog post was about.

The fix was straightforward for existing issues, but it also highlighted something we need to stay on top of: each time we publish a new blog post, we’ll need to manually add appropriate alt text to ensure the thumbnail link is properly described. It’s one of those ongoing maintenance tasks that’s easy to forget but makes a real difference to accessibility.

Missing Form Labels

When someone using a screen reader encounters an unlabeled form field, they get no context about what information should go there. The screen reader can’t announce ’email address’ or ‘phone number’. It just says something like ‘edit field’ and leaves the user to guess what’s expected.

It turned out that the form fields on our contact form was missing proper labels. This would have made it nearly impossible for screen reader users to complete the form successfully.

The fix is straightforward: each form field needs a proper label that’s programmatically linked to it. In Elementor (our page builder), this meant going into each form widget and ensuring every field had both a visible label and the correct accessibility attributes enabled.

Interestingly, WAVE also flagged a missing form label that wasn’t actually visible on our site. A hidden reCAPTCHA field that our form plugin had automatically added. Even though users couldn’t see it, screen readers were still trying to interact with it. We ended up removing that particular reCAPTCHA implementation to clean things up.

Low Colour Contrast Error

Of all the accessibility issues we found, low colour contrast was the only one that required some real thought. Most of the other fixes were fairly straightforward. But this one meant changing one of the key colours in our brand.

Our original ‘Contactzilla green’ used for buttons and calls-to-action, wasn’t passing the required contrast ratio for white text. According to the official WCAG 2.2 guidelines, the minimum acceptable contrast ratio is 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold) against its background. Our primary green colour was coming in at a shockingly low 2.72:1. Waves tells you your ratio and has a slider you can use to audition colours, whilst updating the hex code, contrast ratio and whether you pass or fail with that foreground and background combination.

In the end, our only practical solution was to darken the shade. The colour we settled on comfortably got us over the line, with a contrast ratio of 5.13:1.

If we’d run into this problem when first designing the website, picking a new colour might have felt daunting. But we simply adjusted our brand green, fixed the error quickly, and honestly, we ended up liking the result more.

Some other errors you might run into

While we focused on the main issues we encountered, WAVE can flag many other accessibility problems. Here are some common ones you might see on your site:

Empty Buttons or Links

These appear when clickable elements don’t have any descriptive text. Screen readers can’t tell users what the button does, so they’ll just hear “button” or “link” with no context.

Skipped Heading Levels

If you jump from an H1 straight to an H3, skipping H2, WAVE will flag this. Screen reader users rely on logical heading structure to navigate content, so maintaining the hierarchy (H1→H2→H3→H4) is crucial.

Missing Page Language

WAVE checks whether your HTML includes the language attribute (<html lang="en">). Without it, screen readers might pronounce words incorrectly or struggle with the content entirely.

Redundant Links

When multiple links on the same page lead to identical destinations but use different text, it can confuse screen reader users. WAVE flags these so you can consolidate or differentiate them properly.

Empty Table Headers

Tables need proper headers to make sense to assistive technology. If WAVE finds table cells that should be headers but are empty, it’ll flag them as errors.

Missing Focus Indicators

When someone navigates your site using only a keyboard, they need to see where they are. WAVE will alert you if interactive elements don’t have visible focus states.

The full list of WAVE errors covers everything from ARIA attribute issues to structural problems, but these are the most common ones that trip up small business websites. Each error comes with clear guidance on how to fix it, making WAVE an excellent learning tool as well as a diagnostic one.

Step 5: Creating Our Accessibility Statement

Following guidance from the W3C, we created an accessibility statement for our website and we used this tool to do it: W3C Accessibility Statement Generator. This generator walks you through the key information you need to include.

Our statement includes:

• Our commitment to making the site accessible to people with disabilities
• Which accessibility standard we’re aiming for (WCAG 2.2 Level AA)
• Contact information for users to report accessibility problems
• An honest acknowledgment of any known limitations

We now have a link on the footer of our website to our accessibility statement

What About YouTube Videos?

While we were going through all of this, it occurred to us that we should probably check if our YouTube channel needed any attention too. We’ve always made sure to add captions to our videos, but we wondered if there was anything else we should be thinking about.

It turns out that YouTube’s player is already pretty accessible. It works with keyboards and screen readers without any extra work from us. The main thing is making sure those captions are actually accurate. YouTube’s auto-generated ones are often hilariously wrong, so we always go through and fix them properly.

We’re not embedding loads of videos on our website, but when we do, we learned it’s worth adding a proper description and making sure they don’t autoplay. Beyond that, it seems like we were already doing the right thing without really knowing it.

If we discover there’s more we need to do as we learn about this stuff, we’ll update our process. For now, at least we know our existing videos aren’t creating any obvious accessibility barriers.

Other Accessibility Testing Tools Worth Knowing About

While WAVE proved perfect for our needs, we’d initially researched several other tools that are worth mentioning. Each has its own strengths depending on your technical setup and requirements.

Google Lighthouse is probably the most widely known, built right into Chrome DevTools. It’s excellent if you want to test accessibility alongside performance, SEO, and other metrics in one go. Lighthouse actually uses the same axe-core library as some other tools, so it’s quite reliable, though it tends to find fewer issues than WAVE in side-by-side comparisons. The big advantage is that it’s already there if you’re used to working in Chrome DevTools.

axe DevTools is considered the gold standard by many developers—it’s made by Deque, who are specialists in accessibility. The free version catches a solid range of issues, and the interface is clean and developer-friendly. It organises problems by severity (critical, serious, moderate, minor) which can help you prioritise fixes. The paid version adds guided testing for issues that can’t be detected automatically, but for most small businesses, the free version covers plenty.

Our Resources

Here are the main resources we found helpful:

Standards & Guidance:

• WCAG 2.2 Guidelines (W3C) – the official accessibility standard we’re aiming for (Level AA)
• ADA.gov Web Accessibility Guidance – DOJ overview of how ADA applies online
• Section 508 Standards – useful reference even for non-government sites

Tools:

• WAVE Chrome Extension – free accessibility testing tool
• WebAIM Color Contrast Checker – test your colour combinations
• W3C Accessibility Statement Generator – create your accessibility statement

Help Us Keep Improving

This has been a wake up call for us and while we’ve worked hard to make our site accessible and will continue testing regularly, we know we might have missed something or new issues could emerge as we add content.

If you encounter any accessibility barriers on our website, please let us know. Whether it’s a button that doesn’t work properly with your screen reader, text that’s hard to read, or navigation that doesn’t make sense with a keyboard. We genuinely want to hear about it.

You can reach us at [support@contactzilla.com](mailto:support@contactzilla.com)

Frequently Asked Questions

What is WCAG 2.2 and what does Level AA mean

WCAG 2.2 Level AA is the recommended accessibility standard for most websites. It includes 50 success criteria covering visual, auditory, motor, and cognitive disabilities. Level AA balances comprehensive accessibility with practical implementation for businesses. Level AAA is considered impractical for most commercial sites.

How do I test my website for accessibility compliance?

Use free tools like WAVE browser extension or Google Lighthouse accessibility scan to identify common issues. Check for missing alt text, color contrast problems, and keyboard navigation. These tools catch 60-70% of accessibility barriers but manual testing is also needed for full compliance.

How often should I check my website for ADA compliance?

Websites should be checked for ADA compliance monthly for active sites and after any major updates or content changes. Businesses should also conduct comprehensive accessibility audits quarterly to ensure ongoing compliance with WCAG 2.2 Level AA standards and reduce legal risk.

Can I use accessibility widgets to make my site compliant?

Accessibility widgets provide partial compliance by fixing some common issues automatically. However, widgets cannot address all barriers like poor color contrast, missing form labels, or complex navigation problems. Manual remediation is still required for comprehensive accessibility.

Do small businesses need to make their websites ADA compliant?

Yes, small businesses must make their websites ADA compliant if they serve the public. The Americans with Disabilities Act applies to all public accommodations regardless of business size. This includes restaurants, retail stores, service providers, and online businesses with websites. WCAG 2.2 Level AA is the recommended accessibility standard..

Are there any exemptions to ADA website compliance for small businesses?

No size-based exemptions exist for ADA website compliance. All businesses serving the public must comply with Title III accessibility requirements regardless of employee count. The 15-employee threshold only applies to employment provisions, not websites or public accommodations.