ADA Compliant Website Requirements for Public Entities

If you run the website for a school district, city, county or special district, you have probably been asked some version of "Is our website ADA compliant?" This guide answers that question in plain terms: what an ADA compliant website means under federal law, which deadlines apply to you, what the technical standard actually requires, and how to get there without buying a shortcut that does not work.

This guide is general information, not legal advice. Rules, deadlines and how they apply to a particular entity can depend on facts we cannot see from here. Consult your entity's counsel before making compliance decisions.

What "ADA compliant website" actually means

There is no ADA certification for websites. No federal agency issues a badge, and no vendor can grant one. When people say a site is "ADA compliant," they usually mean it meets a recognized technical standard for accessibility, so that people who are blind, have low vision, are deaf or hard of hearing, have limited dexterity or have cognitive disabilities can use it.

For state and local governments, that standard is now written into federal regulation. On April 24, 2024, the Department of Justice published a final rule under Title II of the Americans with Disabilities Act (89 FR 31320). It added Subpart H to 28 CFR Part 35 and adopted the Web Content Accessibility Guidelines (WCAG) 2.1, Level A and Level AA, as the technical standard for web content and mobile apps (28 CFR 35.200).

So for a public entity, "ADA compliance for websites" has a concrete meaning: your web content and mobile apps conform to WCAG 2.1 Level AA, unless one of the rule's exceptions or defenses applies.

A note on private businesses (Title III)

Title III covers businesses open to the public. The DOJ has not adopted a web accessibility regulation for Title III. Businesses rely on DOJ guidance, which says websites must be accessible but leaves flexibility in how (ada.gov web guidance), and on court decisions, which vary. Many businesses use WCAG 2.1 AA as a practical target. The rest of this page focuses on public entities under Title II.

Deadlines: April 2027 and April 2028

The original 2024 rule set compliance dates in April 2026 and April 2027. On April 20, 2026, the DOJ published an interim final rule that pushed both dates back by one year (91 FR 20902). The rule took effect the day it was published and did not change the technical standard or the exceptions.

Who	Compliance date
Public entities with a total population of 50,000 or more (other than special district governments)	April 26, 2027
Public entities with a total population under 50,000	April 26, 2028
All special district governments, regardless of size	April 26, 2028

"Total population" has a specific definition in 28 CFR 35.104. A city or county uses its decennial Census population. An independent school district uses the Census Bureau's Small Area Income and Poverty Estimates for the district, not the number of enrolled students. Water, fire, transit, library and park districts usually count as special district governments. We cover the details in our post on the extended deadlines and in our guide for special districts.

One caution: the extension did not pause your existing Title II duty to communicate effectively with people with disabilities. A resident who cannot use your bill-pay page today can still file a complaint today.

What the rule covers

The rule applies to web content and mobile apps that a public entity "provides or makes available, directly or through contractual, licensing, or other arrangements" (28 CFR 35.200(a)). In practice that includes:

Your main website and every subsite: school sites, department pages, the library catalog, the parks registration page.
Mobile apps you offer, including district apps for lunch balances or city apps for reporting potholes.
Documents posted online. The rule defines "conventional electronic documents" as PDFs, word processor files, presentations and spreadsheets. Board agendas, budgets and enrollment forms count.
Third-party content you contract for. If a vendor hosts your utility bill-pay portal, your online permit system, your job application site or your embedded calendar, that content is covered because you provide it through a contract.
Social media posts your entity publishes after its compliance date. The posts are your content even though the platform is not yours.
Audio and video on your pages, including recorded board meetings and livestreams.

The five exceptions

Section 35.201 lists five exceptions. They are narrower than many people assume.

Archived web content. Content created before your compliance date (or reproducing older paper documents or media), kept only for reference, research or recordkeeping, not altered after archiving, and stored in a dedicated area clearly labeled as archived. All four conditions must be met.
Preexisting conventional electronic documents. PDFs and similar files posted before your compliance date, unless they are currently used to apply for, gain access to, or participate in your services, programs or activities. A 2019 budget PDF may qualify. A 2019 PDF facility-rental application still in use does not.
Content posted by a third party. For example, comments residents leave on your pages. This does not apply when the third party posts because of a contractual, licensing or other arrangement with you.
Individualized, password-protected documents. Documents about a specific person, their property or their account that are password-protected or otherwise secured, such as an individual water bill PDF. You still must provide an accessible version to a person who needs one.
Preexisting social media posts. Posts made before your compliance date.

The rule also includes limited defenses for fundamental alteration and undue financial and administrative burdens, and a provision on noncompliance that has a minimal impact on access. Treat these as narrow and talk to counsel before relying on them.

What makes a website ADA compliant: WCAG 2.1 AA in plain English

WCAG 2.1 is published by the W3C. Level A and AA together contain 50 success criteria, organized under four principles. Here is what they mean on real school and city sites.

1. Perceivable

People must be able to perceive the content, whether they see it, hear it or use a screen reader.

Text alternatives for images. The most common failure we see is the image-only flyer: a JPG of the fall festival poster with the date, time and location baked into the picture. A screen reader user hears "image" or a file name. Put the details in real text on the page and give the image short alt text.
Captions and transcripts. Recorded board meetings need captions. Auto-generated captions are a starting point, but names, motions and dollar amounts often come out wrong.
Color contrast. Body text needs a contrast ratio of at least 4.5:1 against its background. Light gray text and white text on a pale school-color button often fail.
Structure. Headings must be real headings, lists real lists and tables real tables, so assistive technology can convey the structure.
Reflow and resize. Content should work at 400% zoom without horizontal scrolling for most text.

2. Operable

People must be able to use every control, including with a keyboard alone.

Keyboard access. Every menu, button, form field and embedded widget must work with Tab, Shift+Tab, Enter, Space and arrow keys. Mega menus that open only on mouse hover are a frequent failure.
Visible focus. A keyboard user must see where they are. Many themes remove the focus outline for looks.
Moving content. Homepage carousels that auto-rotate need a pause control. Better yet, drop the carousel and show the two or three items that matter.
Skip links and page titles. Provide a way to skip repeated navigation and give every page a descriptive title.
Enough time. If a payment form times out, users must be warned and given a way to extend.

3. Understandable

Content and interfaces must be predictable and clear.

Labels and instructions. The site search box with only a magnifying-glass icon and no label is a classic failure. So is a registration form that uses placeholder text as its only label.
Error messages. If a parent submits a form with a missing field, the error must be identified in text, not just a red border.
Page language. Declare the page language so screen readers pronounce words correctly, including Spanish pages.
Consistent navigation. Menus should stay in the same place from page to page.

4. Robust

Content must work with current and future assistive technology.

Name, role and value. Custom controls such as accordions, tabs and date pickers must expose what they are and what state they are in. Embedded event calendars from third-party vendors often fail here: a screen reader announces a grid of numbers with no way to tell which days have events.
Status messages. "Your payment was received" must be announced to screen reader users without moving their focus.

Documents count too

PDF agendas and minutes are often the largest accessibility gap on a public site. A scanned agenda is just a picture of text. An accessible PDF needs real text, tags, a logical reading order, headings, alt text for charts and a set document language. For many documents, publishing the content as an HTML page is easier to keep accessible than a PDF.

How to make a website ADA compliant: a step-by-step plan

Inventory what you publish. List every domain and subdomain, every vendor-hosted portal (payments, permits, job applications, enrollment, library catalog), your mobile apps, social accounts and the document libraries. You cannot fix what you have not counted.
Assign an owner. Name one person responsible for accessibility, with authority to hold content editors and vendors to the standard.
Run a baseline evaluation. Combine automated scanning with manual testing (see the next section) on your most important pages and tasks.
Prioritize by task, not by page count. Start with what residents and families must do: pay a bill, enroll a child, apply for a job, find a meeting agenda, report a problem, read emergency notices.
Fix the template first. One fix to the header, navigation, footer or color palette repairs every page that uses it.
Clean up documents. Remediate PDFs that people use to apply for or access services. Move clearly old reference documents into a labeled archive section that meets the four archive conditions. Stop posting scanned PDFs.
Train content editors. Most new failures come from daily publishing: flyers as images, vague link text like "click here," headings chosen for size. A one-hour training and a short checklist prevent much of this.
Hold vendors accountable. Ask vendors for current conformance documentation, and put WCAG 2.1 AA requirements, testing rights and remediation timelines into contracts and renewals. Our procurement page outlines contract language to ask for.
Publish an accessibility statement with a way to report barriers (more below).
Monitor continuously. Sites change every day. Schedule recurring scans and periodic manual checks so regressions are caught early.

Is my website ADA compliant? How to check

No single tool can answer that question. A sound check uses three methods.

Automated scanning

Automated tools are good at finding missing alt attributes, low contrast, missing form labels, empty links and missing page language at scale. They cannot judge whether alt text is accurate, whether a reading order makes sense or whether a custom widget is usable. WebAIM, which runs its own automated tool, says plainly that the absence of detected errors does not mean a page is accessible. Its 2026 WebAIM Million report found detectable WCAG failures on 95.9% of the top one million home pages, with low contrast text on 83.9%, missing alternative text on 53.1% and missing form input labels on 51%. Those are just the failures a machine can see.

You can run a free PillarScan scan to see automated findings for your homepage and key pages. Our scoring methodology explains what an automated score can and cannot tell you.

Keyboard testing

Put your mouse aside and press Tab from the top of your homepage. Can you see where you are at every step? Can you open the menu, use the search box, get through the carousel, register for an event and pay a bill? Can you close a popup? If you get stuck, so does a keyboard user.

Screen reader testing

Try your key tasks with a free screen reader such as NVDA on Windows, or VoiceOver on Mac and iPhone. Listen for unlabeled buttons, images announced by file name, and forms whose fields make no sense out of context. Ideally, include people with disabilities in testing. The W3C's evaluation resources describe how to structure a review.

What an accessibility statement is

An accessibility statement is a public page that says which standard you aim for (WCAG 2.1 Level AA), what you know is not yet accessible, how to request content in an accessible format, and how to report a barrier, with a named contact, phone number and email. It is not a legal shield and should not claim full compliance you cannot support. The W3C provides guidance and a generator for writing one. Link it from your site footer, and make sure someone actually answers the reports.

Overlays are not a fix

Accessibility overlays are scripts that add a toolbar or claim to repair a site automatically. They do not change your underlying code, documents or vendor portals, and they cannot fix an image-only flyer, a scanned PDF or a keyboard trap inside a third-party payment form. Some screen reader users report that overlays interfere with their own assistive technology.

The Federal Trade Commission has also acted on overlay marketing. In April 2025 it approved a final order requiring accessiBe to pay $1 million over allegations that it misrepresented its tool's ability to make websites WCAG compliant (FTC press release). Spend that budget on fixing templates, documents and vendor contracts instead.

Frequently asked questions

Is there an official ADA certification for websites?

No. No federal agency certifies websites as ADA compliant, and no vendor can issue a certification. For state and local governments, compliance means conforming to WCAG 2.1 Level AA as required by 28 CFR Part 35, Subpart H, subject to the rule's exceptions.

What are the ADA compliant website requirements for public entities?

Web content and mobile apps you provide directly or through vendors must meet WCAG 2.1 Level A and AA. Entities of 50,000 or more people must comply by April 26, 2027; smaller entities and all special district governments by April 26, 2028.

Do PDFs and board agendas have to be accessible?

PDFs posted on or after your compliance date must be accessible. Older PDFs can fall under an exception unless people currently use them to apply for, gain access to, or participate in your services, so active forms and applications still need to be fixed.

Are we responsible for vendor sites like bill-pay or permit portals?

Yes. The rule covers web content you provide through contractual, licensing or other arrangements, so a vendor-hosted payment portal or embedded calendar is covered. Put WCAG 2.1 AA requirements in your contracts.

Can an automated scan tell me if my website is ADA compliant?

Not by itself. Automated tools reliably catch only part of the issues, such as missing alt attributes and low contrast. You also need keyboard testing and screen reader testing of key tasks.

Will an accessibility overlay or widget make my site compliant?

No. Overlays do not fix your underlying code, documents or vendor portals, and in 2025 the FTC finalized an order against accessiBe over claims about its tool making sites WCAG compliant.

ADA Compliant Website: A Guide for Schools, Cities and Counties