Stop Guessing! How to Answer ADA Title II Compliance Requests

Stop the ADA request insanity!

The volume of panicked calls and emails we’re getting from ed tech clients right now is both alarming and frustrating. Not because ADA Title II compliance is impossible, but because the confusion around it has reached a point where vendors are making promises they can’t keep, procurement teams are asking for things that don’t exist, and sales reps are nodding along to requirements nobody fully understands.

It’s a crazy mess!!

The DOJ’s final rule under Title II of the Americans with Disabilities Act dropped in April 2024, setting specific deadlines for state and local government entities to bring their digital content into WCAG 2.1 Level AA conformance. Large entities had until April 24, 2026. Now that date has been pushed back to April 2027. All of this has created a real sense of urgency inside government agencies and educational institutions, and a lot of that urgency is now flowing downstream to the vendors who supply them.

The problem is that urgency and clarity rarely travel together. The requests ed tech companies are receiving right now are often vague, inconsistent, or based on a fundamental misunderstanding of what digital accessibility compliance actually requires. If your team doesn’t understand what’s being asked, you’re going to overpromise, underdeliver, or both.

Let’s clear some of this up.

What the DOJ Title II Rule Actually Requires

The rule requires covered entities, which include state and local governments, public universities, school districts, and other public agencies, to make their websites and mobile apps conform to WCAG 2.1 Level AA. That’s the standard. That’s the floor.

What it does not require is perfection. It does not require that every piece of digital content be flawlessly accessible on day one. The DOJ’s own guidance acknowledges that accessibility is ongoing work and that organizations are expected to demonstrate good-faith efforts, documented processes, and a plan for addressing barriers over time.

Procurement teams miss this constantly. When a school district sends a questionnaire asking “Is your product fully ADA compliant?”, that question reflects a misunderstanding of how accessibility actually works. There is no permanent state of full compliance. Products get updated. Standards evolve. Content changes.

What is fully conformant today may have a new issue by next quarter if a developer pushes an update that introduces a keyboard navigation problem.

When your sales or solutions team gets that question, the honest answer is something like: “Our product is actively maintained to conform with WCAG 2.1 Level AA, we have documented accessibility testing processes, and we provide an Accessibility Conformance Report that details our current conformance status.”

That’s a real answer.

“Yes, we’re fully compliant” is a promise nobody can keep. It’s also telling people what they want to hear, not what they need to hear.

A Real Questionnaire, and What the Questions Actually Mean

We recently worked with several ed tech vendors who received a compliance request that opened like this:

“As part of [school district]’s district-wide preparation for compliance with the ADA Title II Web and Mobile Accessibility Rule, we are conducting an audit of all digital applications, platforms, and services used by staff, students, and families. To support accurate compliance evaluation and planning, we request written responses to the following questions regarding your product’s current accessibility status.”

Honestly, that’s a well-constructed request.

The district is doing exactly what it should do: taking inventory of its vendor ecosystem before the compliance deadline hits. The problem isn’t the intent. The problem is that the questions require careful, accurate answers, and most vendors don’t know how to give them. Wrong answers, whether too vague or overconfident, create real exposure down the road.

Let’s walk through each section.

Section 1: Front-End User Experience and Interface Accessibility

This section asks whether your user-facing product has been evaluated against WCAG 2.1 AA, when it was last tested, who conducted the evaluation, whether a report is available, what the known limitations are, and whether your roadmap includes remediation timelines.

These are solid, reasonable questions. They’re asking for the core of what a mature accessibility program looks like, and they deserve honest answers.

“Evaluated” means tested. Not scanned.

Automated scanners like Axe or WAVE are useful starting points, but they catch roughly 25 to 35 percent of WCAG issues. A real evaluation includes manual testing and assistive technology testing with tools like JAWS, NVDA, VoiceOver, and TalkBack. If your most recent evaluation was purely automated, say that. It’s not disqualifying, but it does matter, and the district deserves to know.

“Who conducted it” matters more than most vendors realize. Internal evaluations have value, but an independent third-party evaluation carries more weight. If you used your own team, say so. If you used an external partner, name them. Don’t be vague here.

On known limitations: answer this honestly!!!

If there are known accessibility issues in your navigation, interactive components, or visual design, disclose them and describe what you’re doing about them. The district would much rather know about a gap with a remediation plan than discover it after deployment when a student using a screen reader can’t complete an assignment.

If you have remediation timelines, include them. If you don’t have formal timelines yet, say you’re working on establishing them. Vague assurances don’t help anyone and they don’t hold up if things go sideways. The best answer is transparent about why something is the way it is, what is being done about it, and if it prevents users from doing required tasks.

 Section 2: Back-End and Administrative Interface Accessibility

This one asks whether your admin or staff-facing interface has been tested, whether a report is available, and if not, when testing will happen.

I see vendors get caught flat-footed here all the time because most accessibility attention goes to the end-user/student-facing side of a product. But the administrative interface is where teachers, staff, and administrators work every day, and they have disabilities too. The DOJ Title II rule does not carve out exceptions for internal-use interfaces. (Not to mention that this requirement falls under ADA Title I requirements!)

If you haven’t tested your admin interface, say so and give a realistic timeline. “We plan to complete an administrative interface evaluation by [date]” is a real answer. “Our product is fully accessible” when you’ve only tested the user/student side is not accurate, and a district with a competent accessibility reviewer will catch it.

 Section 3: Document, Report, and Data Output Accessibility

This section is asking whether system-generated outputs, like PDFs, Excel files, HTML reports, and data exports, are accessible and compatible with assistive technologies. It specifically asks about tagging, heading structure, alternative text, logical reading order, and keyboard operability.

This is one of the most overlooked areas of document accessibility, and it trips up vendors who haven’t considered it. A PDF generated by your platform without accessibility tagging is completely inaccessible to a screen reader user. An Excel export without proper structure is the same story. These aren’t edge cases. They’re the everyday work products that people with disabilities rely on.

If your system generates accessible outputs, say so and explain how. If it doesn’t, be upfront and note whether it’s on the roadmap. Districts asking this question are not always looking for a vendor who has solved every output accessibility problem. They’re looking for a vendor who knows the problem exists and is doing something about it. (Keep in mind that PDFs are not the only option you have!)

Section 4: API, Integration, and Embedded Component Accessibility

This section asks whether embedded content, SSO-based widgets, iframes, and integrations have been tested for accessibility, and whether there are known issues affecting assistive technology users.

The fact that organizations and districts are asking this tells me procurement maturity is improving, which is a good thing. Embedded components are a genuine accessibility risk because they often fall into a gray zone where the vendor says “that’s the platform’s responsibility” and the platform says “that’s the vendor’s responsibility,” and meanwhile there’s a keyboard trap in the iframe that nobody owns.

If you’ve tested your embedded components and integrations, provide that information. If you haven’t, acknowledge it. If there are known issues with iframe accessibility, keyboard focus management in widgets, or assistive technology compatibility in integration scenarios, name them and describe how you’re addressing them.

The worst possible answer here is confident silence, implying everything is fine when you haven’t actually checked.

Section 5: Development Roadmap and Compliance Strategy

This section asks which WCAG version you’re targeting (2.1 or 2.2), whether you maintain an accessibility statement or VPAT, and who the district/organization should contact for future accessibility questions and updates.

All three deserve a straight answer.

• On WCAG version: the DOJ Title II rule requires WCAG 2.1 Level AA. WCAG 2.2 is the current published standard and adds success criteria around cognitive accessibility and mobile interactions. If you’re already aligned to 2.2, say so. That’s worth noting. If you’re still working toward 2.1 Level AA conformance, say that clearly and honestly.
• On your VPAT or accessibility statement: you should have one, it should be current, and it should be honest. More on that in a minute. If you don’t have one, don’t imply that you do. If yours is three years old, note the date and tell them when it will be updated.
• On the contact question: don’t underestimate this one. Institutions want to know there’s a real person they can reach when something comes up, not a compliance alias that feeds into a ticketing system that nobody checks. Give them a person or a team who actually understands accessibility and can respond with substance.

The VPAT Struggle Is Real

I need to spend a minute on VPATs because this is where I hear the most confusion, especially from sales teams.

A VPAT, which stands for Voluntary Product Accessibility Template, is the document vendors complete to produce what’s formally called an Accessibility Conformance Report, or ACR. It’s a structured self-assessment where vendors describe how their product conforms to accessibility standards. The current version for web-based products is the VPAT 2.4 Rev WCAG template, published by the Information Technology Industry Council.

Here’s what a VPAT is not: a certification, a guarantee, a seal of approval, or a pass/fail test.

A VPAT is a snapshot of your product’s conformance status at the time of the assessment. No more, no less.

An honest one will include “Partially Supports” or “Does Not Support” entries because almost no complex software fully supports every WCAG success criterion across every possible use case. That’s not a failure. That’s an accurate document! (Btw – also the most legally defensible.)

When a procurement officer asks your sales rep for a “clean VPAT,” they usually mean one of two things. Either they want a document where every line says “Supports,” which would almost certainly be inaccurate, or they don’t fully understand what they’re looking at, and they’re using “clean” as a proxy for “something that won’t get us in trouble.”

The first scenario is a real problem. A VPAT that claims full support for everything is not more reassuring; it’s less trustworthy. Any accessibility professional who reviews it will be immediately skeptical. An ACR with nothing but “Supports” across the board for a complex LMS is a red flag, not a green one.

This is especially dangerous if your product is intentionally designed to do something that “supporting” a criterion would require providing an answer or altering the purpose of the function.

The second scenario is fixable. Procurement teams often need someone to explain what a VPAT actually tells them. That’s a great conversation worth having – but your sales team needs to know how to answer. More on that in a sec.

The only good VPAT is an honest one.

It was completed based on actual assistive technology testing, it accurately reflects where the product succeeds and where work remains, and it was updated recently enough to reflect the current product.

A Word for Your Sales Team

I get it. Sales teams want to close deals.

When a prospect says “we need full ADA compliance,” the reflex is to say “yes, we have that.” That reflex is going to cause you problems.

The better move is to position your actual accessibility program as the differentiator. If you have an honest ACR, an active remediation process, and a real accessibility contact, you are already ahead of most of your competitors. That’s a genuine sales advantage, not a liability!

The districts and institutions sending these detailed questionnaires are increasingly sophisticated buyers. Many of them have been burned by vendors who promised compliant products and delivered platforms that didn’t work with a screen reader. An honest, detailed response builds far more trust than a confident “yes, we’re compliant.”

If your product has gaps, being transparent about them with a remediation roadmap attached is almost always better received than pretending they don’t exist. Serious accessibility procurement isn’t looking for perfection. It’s looking for a vendor who takes this seriously and will work with them over time.

I’m think this topic would make a great companion blog.

Where This Is All Headed

The April 2026 deadline has already been extended to April 2027. However, the market pressure on ed tech vendors to demonstrate credible accessibility programs is not going away. It’s going to keep increasing as institutions get more sophisticated and enforcement picks up.

The companies that come out ahead will be the ones treating digital accessibility the way it actually works: as ongoing operational work, not a one-time project or a box to check before a contract renewal. That means building accessibility into your development and QA process, having someone on your team who genuinely understands WCAG 2.1, maintaining documentation that reflects the real state of your product, and being the kind of vendor partner that institutions actually want to renew with.

The DOJ Title II rule is not a finish line.

It’s the environment your customers are living in right now. The vendors who understand that will have a real advantage with the institutions trying to navigate it.

At Accessiblü, we work with ed tech companies, agencies, and public sector organizations to build accessibility programs that hold up under procurement scrutiny and actually serve users with disabilities. If your team is trying to figure out where to start, reach out and let’s talk through it.