OptimoGov North America
Compliance and accessibility

What ADA Title II actually means for your reservation portal

The rule is not about your website. It is about every page a resident has to get through to book a room, and most agencies have not looked at the second half of that path.

OptimoGovSeptember 2, 20267 minute read

There is a version of this conversation that goes badly. An agency asks its booking vendor whether the product is accessible. The vendor says yes, and sends a document about its own marketing website. Eighteen months later somebody files a complaint about a resident who could not complete a pavilion reservation with a screen reader, and the agency discovers that the assurance it relied on covered the wrong pages.

So it is worth being precise about what the rule requires and where the scope actually falls.

What the rule says

The Department of Justice final rule under Title II of the Americans with Disabilities Act requires state and local government web content and mobile applications to conform to WCAG 2.1 Level AA. It was published in April 2024. On April 20, 2026 the Department published an interim final rule extending both compliance dates by one year. The standard itself did not change.

  • Public entities with a total population of 50,000 or more: April 26, 2027, extended from April 24, 2026.
  • Public entities under 50,000, and any special district government: April 26, 2028, extended from April 26, 2027.
Worth noting if you are a district

The second tier names special district governments with no population threshold. An independent park and recreation district is in scope regardless of how small it is. That surprises a lot of district directors.

Where the scope actually falls

The phrase to hold onto is web content and mobile applications. Not website. If a resident interacts with it to obtain a service from you, it is in scope, and that includes things your vendor generates on your behalf.

For a reservation and registration portal, the real scope is the whole path:

  1. Discovery. Browsing facilities by location, capacity, amenity or date. Filters, maps and calendars are where keyboard traps usually live.
  2. Availability. The calendar view. Date pickers are the single most common accessibility failure in booking software.
  3. Application. The form, including document upload, conditional questions and error handling. If a validation message appears only as a red outline, it does not exist for a screen reader user.
  4. Signature. The waiver. An e-signature component embedded from a third party is still on your page and still in your resident's path.
  5. Payment. Usually rendered by a gateway. Still part of the service.
  6. Confirmation. The email. Then the invoice. Then the permit PDF. A permit issued as a flat image of a document is not accessible, and it is the thing the resident actually has to keep.

Most conformance claims in this category cover steps one to three. The complaints tend to come from steps four to six.

The four questions worth asking your vendor

Whether that is us or anyone else, these are the questions that separate a real position from a reassuring one.

1. Can you send me the accessibility conformance report for the resident-facing portal?

Not an accessibility statement. Not a VPAT for a different product. A conformance report for the pages residents use. If the answer takes more than a week, you have learned something.

2. What are the generated documents?

Permits, invoices, receipts and confirmations. Ask whether they are tagged PDFs. Ask to see one and run it through a checker yourself. This takes four minutes and it is the fastest way to find out how seriously a vendor has taken the question.

3. Which components are third party, and what do you hold on each?

A payment gateway, an identity provider or a mapping component may render its own screens inside your path. A good answer names them and supplies what the vendor holds for each. A bad answer does not know.

4. Who is the named accessibility contact and what is the response commitment?

Under the rule you will need a route for residents to report a barrier. If your vendor has no named contact and no stated response time, that burden lands entirely on your staff.

What to do in the next quarter

If your compliance date is April 2027, you have less runway than it sounds, because a procurement plus an implementation is most of a year.

  1. Audit the path, not the site. Have somebody attempt a real booking with a keyboard only, then with a screen reader. Document where they stop. This costs nothing and it produces the evidence your ADA coordinator needs to justify a budget request.
  2. Request the conformance report from your current vendor in writing. The response, or the absence of one, is the beginning of your business case.
  3. Check the generated documents. Take one permit and one invoice and test them.
  4. Write the requirement into your next solicitation properly. Ask for a conformance report covering the resident path including generated documents and third-party components, as a deliverable rather than a claim.

Our own position

We build the resident portal to WCAG 2.1 Level AA, we test with keyboard and screen reader on the resident paths, we generate permits and invoices as tagged PDFs, and we will give you a conformance report to file. We also publish our own accessibility statement with its known limitations, including the fact that facility descriptions and images your staff upload are your content and the platform will not stop somebody skipping the alternative text.

We would rather you ask us all four questions above and check the answers than take this paragraph at face value.

See it against your own facilities.

Forty-five minutes, your fee schedule, your approval rules, your three hardest cases. No slides.