The free tools that find most of it
You do not need to buy anything to find the majority of accessibility problems on a small business site. The useful tools are already on your computer or free in your browser.
You do not need to buy anything to find the majority of accessibility problems on a small business site. The useful tools are already on your computer or free in your browser.
Short answer
Most accessibility problems on a business site can be found with free tools: a browser extension that scans a page, the screen reader built into your operating system, the tab key, and the browser zoom control. Paid platforms add scale and reporting. They do not find a different class of problem.
Browser extensions that scan the page you are looking at are the fastest first step. They report missing labels, contrast failures, heading problems and invalid attributes in seconds.
Run one on your homepage, your contact page and one deep page. Those three usually represent every template you have.
Read the findings rather than counting them. A single unlabeled field on the contact form matters more than a dozen notices on a decorative section.
Run it on three pages rather than one: the homepage, a contact page and a deep content page. Between them they usually exercise every template a site has.
Windows and macOS both include one at no cost, and both phones have one built in. This is the most useful tool there is. Almost nobody uses it.
You do not need to become proficient. Turn it on, close your eyes, and try to find your own phone number or complete your own form.
Five minutes will teach you more about your site than any report. It is uncomfortable the first time and it stops being so quickly.
Turn the speech rate down first. The default on most systems is faster than a newcomer can follow, and fighting the rate is what makes people give up in the first minute.
No install, no account. Press tab from the top of a page and watch the highlight move.
You are checking three things: that you can reach everything, that you can always see where you are, and that the order is sensible.
This finds hover only menus, invisible focus styling and popups you cannot escape, which together account for a large share of real world complaints.
Enlarge the text in your browser substantially and look at what happens. Text should get bigger and the layout should adapt.
What you are looking for is content that overlaps, gets cut off, or forces the page to scroll sideways. Sideways scrolling at high zoom is a common and serious failure.
Do the same on a phone in portrait. That combination catches most layout problems that affect readers with low vision.
Extensions and design tools will read a pair of colors and tell you whether they pass. Use one while choosing a palette rather than after building the site.
Also view a page in grayscale, which your operating system can do. Anything that becomes ambiguous was relying on color alone to carry meaning.
Do both themes if you offer a dark mode, since the second palette is usually the untested one.
Scale and record keeping. Scanning hundreds of pages on a schedule, tracking issues over time, producing reports for somebody who needs them.
That is valuable for a large site or a team with an obligation to demonstrate progress. It is rarely necessary for a site of a few dozen pages.
They do not find a different class of problem. The judgment gap stays the same whatever you spend.
They also add scheduling and history, which matters if somebody has to demonstrate progress to a buyer or a board. For a site of a few hundred pages, the free tools find the same faults.
Scan your templates, fix what the scanner reports, walk the site with the tab key, then listen to your two most important pages.
Then read your own alt text against the images, because that is the failure no tool will ever report.
Every page written by Website Builder Studio passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards, and the in-app assistant names what still needs a person. None of this is legal advice.
The list itself is set out page by page in the accessibility checklist, which is the version to work through rather than read.
Any of the well known open source scanners will do. They largely share the same underlying rule engine, so the findings are comparable.
As a trend, yes. As a claim, no. A score reflects the checks that tool ran, not conformance, and different tools score the same page differently.
Yes, and you should. Checking at build time is how a problem gets attributed to the change that caused it, rather than discovered months later.
A real phone is better. Browser emulation is a good first pass but misses touch target sizes and how a phone screen reader behaves.
15-day free trial. Card required. Cancel before day 15 and you pay nothing.