A web accessibility checklist for clients: what to check before your site goes live

You do not need to become an accessibility expert to hold your website project to a real standard. You need a list you can actually read. That is what this web accessibility checklist for clients is: a plain-English set of checks you can hand to whoever builds your site, or run yourself before launch, without learning to code.
Here is the number that makes it worth your time. More than 1 in 4 US adults lives with a disability, according to the CDC. So an inaccessible site turns away a big share of your customers without anyone noticing, and most of the fixes are decisions you can see and check, not obscure code buried in the build. Below, each item explains what to check, why it matters, and whose job it is: your team’s to build, yours to check, or a shared call.
This is general information, not legal advice. Accessibility law depends on your situation and where you operate. For advice about your specific business, talk to a qualified attorney.
How to use this checklist
Think of this as a shared reference, not a test you spring on someone at the end. The cheapest time to build accessibility in is before anyone starts, so the best move is to put this list in the brief. That way your designer and developer know the bar from day one.
You can also use it two other ways. Run it as a pre-launch review, going item by item before the site goes live. Or use it to sanity-check work you have already paid for, so you know whether you got what you needed. Either way, you do not have to hit every point at once. Later on, there is a short priority order for tight budgets.
First, one honest word about the law
You may have heard that your business must meet a specific standard by a specific date. For private businesses, that is not quite how it works. The Americans with Disabilities Act does apply to what you offer online, so “there is no law” is wrong. Still, the Department of Justice has not forced one technical checklist on private companies, and in its web accessibility guidance it says businesses “have flexibility in how they comply.”
So why aim for a standard at all? Because in practice, courts and settlements treat the Web Content Accessibility Guidelines (WCAG) at Level AA as the yardstick, and building to it serves more than a quarter of your customers at the same time. The dated 2027 government deadline you may have seen applies to state and local governments, not to private business. For the full picture of what the law actually says, our companion explainer on website accessibility for small business covers it in plain English. This checklist just gets on with the practical part.
The web accessibility checklist
Color and contrast
Check that text has enough contrast against its background, and that you never use color alone to signal something. Your brand palette is your call, but making it readable is your designer’s job. Pale gray text on a white background can look elegant and still fail real users with low vision. Because changing brand colors after launch is expensive, ask your designer to run a contrast check before the palette locks in. It takes a minute and settles the question.
Copy and headings
Check that the writing is plain and that headings follow a real order, not just a big-looking style. Screen readers use headings to jump around a page, so a logical structure is how many people navigate. Since you often own the copy, write clearly and let your designer map the heading levels properly. In other words, headings should describe the sections in sequence, the way a table of contents would.
Images and alt text
Check that every meaningful image has alt text, which is a short written description a screen reader reads aloud. This is usually a shared job. You know what an image is meant to communicate, and your team writes that into the site. As a rule of thumb, describe the purpose of the image rather than every detail, and skip alt text on purely decorative graphics so you do not add noise.
Links and buttons
Check that links and buttons say what they do. “Download the brief template” tells everyone where they are headed, while “click here” tells a screen-reader user nothing once it is read out of context. This is mostly the job of whoever writes and builds the site, but you can spot it in a draft. As you review, read the links on their own and ask whether each one still makes sense.
Video and audio
Check that video has captions and, ideally, a transcript, and that nothing loud plays automatically. Deaf and hard-of-hearing customers rely on captions, and so does anyone scrolling with the sound off, which is most people on a phone. Captions are usually a shared task: you supply the video, your team adds the captions. Autoplay audio, on the other hand, is both annoying and a genuine barrier, so it is worth cutting.
Navigation and keyboard
Check that the whole site works with a keyboard alone, and that you can always see where you are. Many people navigate by tabbing through links, menus, and buttons instead of using a mouse. This part mostly belongs to your developer, but you can still test it. Try tabbing through a demo page yourself, and if the focus outline disappears or you get stuck, so will some of your customers.
Forms
Check that every form field has a clear label tied to it, and that error messages explain what to fix. Forms are where a lot of accessibility problems hide, and they are also where you lose sales when something breaks. Labels and helpful errors are mostly the developer’s job. Even so, you can test a form by filling it in badly on purpose and seeing whether the site tells you what went wrong in plain words.
The two-minute self-test
Check the whole thing yourself, because you do not need special tools to catch the biggest problems. First, tab through the site with your keyboard and see whether you can reach everything. Next, zoom the page to 200 percent and check that nothing breaks or disappears. Then mute your speakers and watch a video to see whether you can still follow it. Finally, run a free contrast or accessibility checker on a key page. None of that requires an expert, and all of it tells you something real.
If your budget is tight, do these first
You do not have to do everything at once. Ask your team to start with the fixes that remove the biggest barriers for the least effort.
- Fix color contrast on text and buttons.
- Add alt text to every meaningful image.
- Make sure the whole site works with a keyboard.
- Label every form field and write clear error messages.
- Add captions to any video.
One warning while you prioritize: skip the “accessibility widgets” and overlays that promise instant compliance from a single line of code. They do not actually make a site conform, and real accessibility comes from how a site is designed and built. Our companion explainer on website accessibility for small business covers why that shortcut backfires.
Put it in the brief, not the post-mortem
Accessibility is not a separate project you tack on at the end. It is a set of choices spread across color, copy, images, and structure, and most of them are decisions you already have a say in. So the real value of this checklist is timing. Hand it over at the start, ask whoever you hire to build to it, and you turn a vague worry into a clear, checkable standard. If you want help reading the signals of a team that takes this seriously, our guide on how to tell if the creative team you are hiring has their systems in order walks through what good process looks like, and our take on startup website design covers where accessibility fits alongside everything else.
The point is not to fear a lawsuit. The point is that a site more people can use is simply a better site, and now you have the list to hold it to that.
Building or rebuilding a site and want accessibility handled properly from day one? Start with The Blue Mango. We match you with vetted creators, scope the work clearly, and build accessibility in from the brief, not after the fact.