Most business owners have thought about the ramp to their front door. Fewer have thought about the website version of it.
An accessible website is one that people with disabilities can use. Someone who is blind may use a screen reader, software that reads the page aloud. Someone who can't hold a mouse may get around with the keyboard, or by voice. Someone with low vision may zoom in, and someone who is deaf may rely on captions. The US Department of Justice compares an inaccessible website to steps at the entrance of a building (ADA.gov).
You can check for the common problems yourself. Here's the standard behind it all, seven checks to run on your own site, and what the law and regulators actually say.
WCAG, the standard behind it
The Web Content Accessibility Guidelines (WCAG) come from the World Wide Web Consortium (W3C), which develops standards for the web. The latest version, WCAG 2.2, was published on October 5, 2023, and updated in December 2024 (W3C). A site that meets WCAG 2.2 also meets the earlier 2.1 and 2.0.
WCAG 2.2 has 13 guidelines under four principles (Understanding WCAG 2.2):
- Perceivable: people can take in the content with the senses they have. A photo needs a text description for someone who can't see it.
- Operable: people can use the controls. A menu that only works with a mouse fails this.
- Understandable: people can follow the content and how the site works.
- Robust: the code is solid enough to work with a wide range of browsers and assistive technology, such as screen readers.
Each guideline has testable success criteria at three levels. Level A is the minimum. Level AA means meeting every A and AA criterion. Level AAA adds the rest, and W3C doesn't recommend requiring it for whole sites, because some content can't meet all of it (WCAG 2.2). The Department of Justice's 2024 rule for state and local governments, covered below, uses WCAG 2.1 Level AA.
Checks you can run yourself
Each of these is a WCAG requirement, and most have a free walkthrough in W3C's Easy Checks. W3C is clear that its checks are a first look, not a full review: a page can pass them and still have serious barriers.
1. Describe your images
Every image that carries information needs a text alternative, called alt text, that a screen reader reads in its place (WCAG 1.1.1, Level A). W3C's images tutorial sorts images by job:
- A photo or illustration that informs: a short description of what matters. "Our storefront on Main Street, with a ramp to the door."
- A picture that's only decoration: an empty alt text, so screen readers can ignore it. Leave it out entirely and some screen readers read out the file name instead (W3C).
- An image that's a link or button: say what it does, not what it looks like. A magnifying glass that opens search is "Search".
- An image with words in it: the alt text repeats the words.
Easy Checks has a bookmark tool that marks every image on a page that's missing alt text.
2. Check your color contrast
Text needs enough contrast against its background: a ratio of at least 4.5 to 1 for regular text, and 3 to 1 for large text, meaning 18 point (about 24 pixels) or 14 point bold (about 18.5 pixels) (WCAG 1.4.3, Level AA). The Justice Department's example of poor contrast is light gray text on a light-colored background.
For a rough check, W3C suggests viewing the page in grayscale and seeing what's hard to read (Easy Checks: color contrast). For an exact one, a contrast checker compares two colors and tells you whether they meet the ratio.
While you're at it, don't let color carry a message alone. The Justice Department's example is a form that marks required fields only in red: add the word "required" too.
3. Put the mouse away
Everything on the page should work from a keyboard (WCAG 2.1.1, Level A), and you should always be able to see where you are (WCAG 2.4.7, Level AA).
Open your homepage, click once on a blank part of the page, and press Tab, again and again. Each press should move a visible highlight to the next link, button or form field. Can you reach the menu, open it, and get to your contact form? If the highlight disappears, or you get stuck, that's a barrier for anyone who doesn't use a mouse (Easy Checks: keyboard focus).
4. Use real headings
Headings work like a table of contents, and screen reader users jump from one to the next to find their way around a page. A page usually has one main heading, with the levels below it nested in order, like a book's chapters and sections, never skipping a level (Easy Checks: headings).
Watch for text that looks like a heading but isn't marked as one, such as a line made big and bold by hand. Screen reader users can't jump to it. In your site's editor, use the heading styles instead. And make each heading say what follows (WCAG 2.4.6, Level AA).
5. Label every form field
Every field on your contact or booking form needs a label that says what goes in it (WCAG 3.3.2, Level A), and the label has to be connected to the field in the code, so a screen reader can announce it.
Here's a quick test from W3C: click on a field's label. If it's connected properly, the cursor jumps into the field (Easy Checks: form labels). While you're on the form, send a test with a mistake in it. The Justice Department says people using screen readers should be told automatically when they've filled in a field wrong, what the error is and how to fix it.
6. Make link text say where it goes
The purpose of each link should be clear from its text, or from the text around it (WCAG 2.4.4, Level A). W3C asks for link text that makes sense on its own wherever possible, because screen readers can list every link on a page (Understanding 2.4.4). A list of five "click here" links tells nobody anything. "See our menu" and "Book a table" do.
7. Caption your videos
Prerecorded videos with sound need captions (WCAG 1.2.2, Level A). Watch your own with the captions on. W3C says that if the only captions are auto-generated ones, sufficient captions aren't provided. Good captions are punctuated, in sync, say who's speaking, and include important sounds (Easy Checks: captions).
One more from the Justice Department's list: give people a way to report a problem, so you can fix it. It can be as simple as a line on your contact page asking visitors to tell you if something on the site doesn't work for them.
What the law says
This is general information, not legal advice.
The Americans with Disabilities Act (ADA) covers businesses open to the public under Title III, and the Justice Department's examples include shops, banks, hotels, medical offices and restaurants. Its guidance on web accessibility, published in March 2022 and still on ADA.gov, says the department has consistently taken the position that the ADA applies to what those businesses offer on the web.
The same guidance says the department has no regulation setting out detailed web standards (the 2024 rule below changed that for state and local governments). Businesses can choose how they make what they offer online accessible, but they still have to make it accessible. The department points to WCAG, and to the Section 508 standards the federal government uses for its own websites, as helpful guidance.
You may have read about the department's 2024 web rule. That rule is for state and local governments, under Title II: their web content and mobile apps generally have to meet WCAG 2.1 Level AA. In April 2026 the department pushed its deadlines back to April 2027 for governments serving 50,000 people or more, and April 2028 for smaller ones and special districts (ADA.gov fact sheet). It also covers web content someone else provides for a government under an arrangement, so a website or app a business runs for a city or county can be covered.
About accessibility overlays
An overlay is a tool added to your site that tries to find or fix accessibility problems automatically. The Justice Department's guidance says automated checkers and overlays can be helpful tools but need to be used carefully, and that a clean report doesn't necessarily mean everything is accessible.
The Federal Trade Commission has acted on one overlay maker's claims. In January 2025 it alleged that accessiBe's accessWidget plug-in did not make all websites WCAG-compliant, as the company claimed. Its final order, in April 2025, required accessiBe to pay $1 million and bars it from claiming its automated products can make any website WCAG-compliant unless it has the evidence (FTC).
If you're having a site built
Ask whoever builds it which WCAG level they design to, and run the checks above on the preview before you approve the design. A problem caught on the preview is easier to fix than one found after launch.
If you'd like me to build it, every plan includes a customized design with two revision rounds on the approved design, mobile and speed optimization, on-page SEO (the page titles, descriptions and headings), and a contact form that emails you. Starter is five pages for $2,400, Deluxe seven for $4,080 and Premium ten for $6,720, each one build fee: paid in full for 10% off, or half now and half before launch. From launch day, the $79/mo care plan covers hosting on Vercel with SSL, daily backups, uptime monitoring, and security and dependency updates.
Compare the plans, or start your project.
