Our Website Vendor Says We're ADA Compliant. Are We?

Who is responsible under Title II?

Your district is. The Department of Justice's Title II rule applies to the web content a public entity makes available, whether the entity built the site itself or pays a vendor to build and host it. DOJ's own fact sheet on the rule uses calendars, scheduling tools, maps, reservation systems and payment systems built by outside technology companies as examples of content that usually still has to meet WCAG 2.1 AA, because the government is the one posting it.

Your contract can decide who pays for fixes and how fast they happen. It generally does not move the legal obligation to the public. Read your own agreement's accessibility language: it often draws exactly the line described below, between the platform and the content you control.

What the platform usually handles

Most major school website platforms advertise themes built to WCAG 2.1 AA and editors with accessibility help built in, and many do real work here. The parts a platform is positioned to get right are the parts that repeat on every page:

• the navigation menus and how they behave with a keyboard;
• page structure, landmarks, and the "skip to content" link;
• the theme's colors and fonts;
• built-in components such as tabs, accordions and slideshows; and
• editor features, like prompting for an image description when someone uploads a photo.

If one of those is broken, it is broken everywhere, and it is a ticket for your vendor.

What a platform cannot fix for you

A platform cannot write accurate alt text for the photos your staff upload, read the date and time baked into an event flyer image, make the PDFs you post readable, caption your videos, or rewrite a link that says "click here." Those are content decisions, made by many people, every week, and they are where most day-to-day accessibility problems come from.

The usual suspects on school sites:

• Images. Alt text that is missing, a camera filename, or two words describing a flyer that contains a date, time and location.
• PDFs. Board packets, menus, handbooks and forms, often scanned or exported without tags. See our guide to which old PDFs have to be accessible.
• Link text. Pages full of "read more" and "click here."
• Color choices in the editor. Custom text colors and text placed over photos.
• Embedded tools from other companies. Athletics schedules, lunch menus, forms, payment pages and calendars that your platform displays but did not build.
• Video. Board meetings and announcements without accurate captions.

For the numbers behind that list, see what we actually find on school websites.

What built-in checkers catch, and what they miss

Editor checkers are genuinely useful, and they vary by platform, so learn what yours covers. In general, an editor checker can tell you an image has no alt text. It usually cannot tell you whether the alt text that is there describes the image. It usually does not open the PDFs linked from the page, look inside embedded tools from other companies, or measure contrast for text sitting on top of a photo. And it checks a page when someone edits it, not months later when a slideshow, an embed or a theme update has changed what visitors actually get.

Seven questions to ask your website vendor

1. Which WCAG version and level is our theme tested against, and when was it last tested? (The Title II rule's standard is WCAG 2.1 AA.)
2. Who did that testing, and can we see an Accessibility Conformance Report (ACR, sometimes called a VPAT) for the platform?
3. When we find a barrier in the template, how do we report it, and how quickly is it fixed?
4. What exactly does the built-in checker check? Does it look at PDFs, embedded content, or contrast?
5. Who is responsible for custom features your team built specifically for us?
6. Which tools on our site come from other companies, and who do we call about each one?
7. What does our contract say about accessibility, and what does it leave to us?

How to split the work

The practical move is to sort every problem by who can fix it. Template problems go to your vendor as tickets. Content problems go to the people who post content, with a little training and a way to catch new ones. Problems inside another company's embedded tool go to that company, or become a reason to replace the tool. Our free audit sorts each finding exactly this way, into what your content team can fix and what belongs with your web developer or vendor.

Does this mean our vendor is doing a bad job?

Usually not. Most of the vendors we see take accessibility seriously, and the template is often the strongest part of a school site. The gap is structural: the platform ships once, and the content changes every day. Walking into a vendor meeting with a specific, screenshotted list of template issues is the fastest way to get them fixed, and it keeps the relationship a partnership.