ADA Compliant Website for MSPs and Tech Companies: What WCAG Asks For

An ADA compliant website isn’t a legal status. It’s shorthand for a site that meets WCAG, usually at Level AA, and has its real barriers fixed. Here’s how that plays out for an MSP.

Let’s invent a firm. Forty people, managed IT, a decent run of three years. A city’s purchasing office emails a vendor questionnaire, and line 14 asks whether the company website conforms to WCAG 2.1 Level AA.

Nobody in the building knows. The owner forwards it to the marketing manager, who forwards it to the agency that built the site in 2022. The agency replies with a screenshot of a widget and two words, “all set.”

It reads like an answer. It isn’t one, because nobody tested anything and the agency’s contract ended the week the site launched.

That’s the gap. A site gets built, handed over and left to drift, and each group involved assumes another group is watching. Not a plugin problem. An upkeep problem.

What an ADA Compliant Website Actually Means

An ADA compliant website is one whose content people with disabilities can perceive, operate and understand, usually measured against the Web Content Accessibility Guidelines (WCAG). The phrase is common shorthand. It isn’t a legal status, and nobody hands you a badge for it.

The U.S. Department of Justice says so itself. Its web guidance states that the Department does not have a regulation setting out detailed standards for web accessibility, although its longstanding interpretation of the ADA’s general nondiscrimination and effective communication provisions applies to the web. It points to WCAG and the federal Section 508 Standards as helpful guidance. Read that twice. Helpful guidance, not a checklist the law prints.

One caution on that page. It is dated March 18, 2022, and it carries a note that it does not reflect the requirements for state and local governments published in the Federal Register on April 24, 2024. Which brings up the question that matters for a tech company. Which rule covers which site?

Which Rule Covers Which Site

The ADA has two parts that matter here. Title II covers state and local governments. Title III covers businesses open to the public. The DOJ’s guidance describes both as covering what they offer on the web.

Title II now has a specific web rule. The DOJ’s fact sheet says the rule makes WCAG 2.1, Level AA the technical standard for state and local governments’ web content and mobile apps. On April 20, 2026, the Federal Register published an interim final rule that moved the dates, so entities serving a population of 50,000 or more now have until April 26, 2027, while smaller entities and special district governments have until April 26, 2028.

Title III has no equivalent rule in the DOJ pages we read on November 10, 2026. That is the gap people argue about, and it’s the reason a lawyer, not a blog post, should answer questions about your own exposure.

So where does an MSP or a tech company land? In three different places. Easy to mix up.

Row two is the one tech firms miss. The same fact sheet says that state and local governments that contract with other entities to provide public services must make sure those contractors follow Title II, and it even gives an example, a city parking app run by a private company, which has to meet the standard. If you build or host something for a public client, that line is about you.

What WCAG Asks of an ADA Compliant Website

WCAG is published by the World Wide Web Consortium (W3C). Version 2.2 has 13 guidelines organized under four principles, and each guideline carries testable success criteria at three levels, A, AA and AAA, and the W3C’s overview says those success criteria are what determine conformance. Four principles. Learn them once.

• Perceivable. People can take in the content, whether they see it, hear it or use a screen reader.
• Operable. Every control works without a mouse, and nothing traps a keyboard user.
• Understandable. Labels, instructions and error messages say what they mean.
• Compatible. The code works with assistive technology, today and later.

Level AA is the target. The DOJ chose WCAG 2.1 Level AA for Title II, and it’s a sensible target for any site. Level AAA sounds better, but the W3C itself says in the standard that it is not recommended that Level AAA conformance be required as a general policy for entire sites, because some AAA criteria can’t be met for some content. Don’t chase it site-wide.

Then there’s the version question. WCAG 2.2 is a W3C Recommendation, and the version of record is dated December 12, 2024. The standard states that content which conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, and the W3C advises using 2.2, although the Title II rule still names 2.1. So test against 2.2 Level AA and you cover both. Version 2.2 also retired a criterion, 4.1.1 Parsing, which the W3C calls obsolete.

Where Tech Company Sites Fail

Open the DOJ’s guidance and its barrier list reads like a punch list from any site review: text too faint to read, meaning carried by color alone, pictures with no description, videos without captions, forms a screen reader can’t make sense of, and pages that stop working the moment you put the mouse down. None of it is exotic. All of it lasts, because it hides in plain sight.

The right-hand column is the uncomfortable part, because every entry is something a marketing team can create in a single afternoon without meaning to, and none of it shows up in a report anyone reads. Say a new hero image goes up with no description, the demo video is published before anyone orders captions, and the designer picks a soft gray because it looks calm.

Contrast is the easy one to see. WCAG asks for a ratio of at least 4.5:1 for normal text at Level AA, and the gray you love on a white background often falls short. Your eyes may not tell you, so check the numbers with a contrast tool instead of trusting the screen. (And yes, the soft gray usually loses.)

Test Like a Person, Then Like a Tool

Automated checkers are useful. They find missing alt attributes and low contrast in seconds. But the DOJ’s guidance is blunt about their limits: checkers and overlays need to be used carefully, because a “clean” report does not necessarily mean everything is accessible. It also says a few reported errors don’t automatically mean a barrier exists. Pairing a manual check with an automated one gives a better read.

So start with a person. Thirty minutes. One browser. No tool yet.

1. Put the mouse away and tab through the homepage. Can you reach every link, menu and button, and can you always see where you are?
2. Fill out the contact form with the keyboard only, and submit it with one field wrong. Does the error say what happened and where?
3. Zoom the browser in until the text is large. Does anything overlap or disappear?
4. Open your newest demo video with the sound off. Do captions carry the message?
5. Read the page headings in order, as a list. Does the outline make sense without the design around it?

Then run a scanner and compare. Where the two disagree, trust the person. The DOJ also notes that websites giving the public a way to report accessibility problems let their owners fix what the checks missed, and a short note with an email address in the footer costs next to nothing.

Keeping an ADA Compliant Website Compliant After Launch

This is where it tends to break. A site gets audited, fixed and signed off. Then a page builder update changes the focus styles, marketing adds a pop-up that traps the keyboard, and someone uploads forty photos with camera filenames standing in for alt text, all within six months of the sign-off. Nobody broke the rules on purpose. The site just kept moving. Nobody was assigned to watch.

More tools won’t fix that. A routine will.

Give accessibility one named owner, even when the work is split across a web developer and a content editor. Add a short accessibility check to the release list, the same list that covers updates and backups. Our website maintenance checklist shows how that kind of recurring list is built. Set content habits for the people who publish: describe every image, caption every video, and write link text that makes sense out of context.

Some of this overlaps with search work. Clear headings, descriptive page titles and meaningful link text help both people and crawlers, and our technical SEO services page covers the search side of that overlap. Accessibility has its own goals, though. Don’t treat it as a side effect of SEO.

Four Weeks to a Working Routine

1. Week one, decide which of the three situations in the table above applies to you, and write down who owns accessibility.
2. Week two, run the thirty-minute manual check on your five busiest pages, then a scanner, and list what you find.
3. Week three, fix the barriers that block a form, a menu or a video, and set the content habits for everyone who publishes.
4. Week four, add the check to your release list and put a way to report problems in the site footer.

Step back and this isn’t a one-time project. It’s the same maintenance discipline you already apply to uptime and security, pointed at the people who use the site, and without it the fix doesn’t compound. It decays.

Not complicated. Just often overlooked. If you want a second set of eyes on how your site is run day to day, book a growth strategy call.