WCAG 2.1 AA for Florida public entities, explained without the legalese

For most of the ADA's history there was no named technical standard for websites. Public entities were told their services had to be accessible, then left to interpret what that meant for a web page. That ambiguity ended in April 2024, when the Department of Justice published a rule under Title II adopting WCAG 2.1 Level AA as the standard for state and local government websites and mobile applications.

In April 2026 the DOJ issued an interim final rule extending the compliance dates by one year. The standard itself did not change.

The dates

• April 26, 2027 for public entities with a total population of 50,000 or more
• April 26, 2028 for public entities under 50,000, and for special district governments
• The Department of Health and Human Services set parallel dates for federally funded healthcare providers, in May of 2027 and 2028

We build websites. We are not attorneys, and this is not legal advice. Whether a particular deadline reaches your organization depends on facts your counsel should evaluate. What follows is an explanation of the technical standard, which is the part we can speak to with authority.

Who this reaches, including people who do not expect it

The obvious group is cities, counties, school districts, public colleges, and state agencies. Two less obvious groups matter in Florida.

Special district governments are named explicitly. Florida has a great many of them, including community development districts, and they are governed entities publishing budgets, meeting notices, and governing documents to the public.

The second group is vendors. Public entities cannot discharge their obligations by outsourcing them, so conformance requirements tend to flow down through contracts to the companies building and hosting the site. If you subcontract to a public entity, read your contract language.

What WCAG 2.1 AA actually asks for

The standard is organized around four principles, and stripped of the formal language they are reasonable expectations rather than exotic ones.

Perceivable. Anything that carries meaning must be available in more than one way. Images need meaningful alternative text. Video needs captions. Color alone cannot be the only thing distinguishing one state from another, because a person who cannot see the difference between red and green gets no information from it. Text needs sufficient contrast against its background, which is a measurable ratio rather than a judgment call.

Operable. Everything achievable with a mouse must be achievable with a keyboard, in a sensible order, with a visible indicator of where you currently are. Nothing may trap focus. Timed interactions need to be adjustable. Content must not flash in ways known to trigger seizures.

Understandable. Language is declared so screen readers pronounce correctly. Navigation stays consistent. Form fields are labeled, errors are described in text rather than color, and the user is told how to fix them.

Robust. The markup is valid and correctly structured so assistive technology can interpret it. Custom components report their name, role, and state.

The failures we see most often

1. Contrast that was chosen by eye. Brand palettes are usually developed for print or for aesthetics, and the ratios were never calculated. This is the single most common failure and one of the easiest to fix.
2. PDFs. Public entities publish enormous quantities of them, and a scanned document is an image with no text layer at all. The rule covers content, not just pages.
3. Forms without proper labels. Placeholder text is not a label. It disappears when typing begins and screen readers handle it inconsistently.
4. Keyboard traps in modals and menus. A dialog you can open but not escape without a mouse is a hard failure.
5. Video without captions. Meeting recordings and public notices are frequently posted with no captions and no transcript.
6. Custom widgets built from generic elements. A clickable div is invisible to assistive technology unless it is given the role and keyboard behavior of a real control.
7. Focus indicators removed for aesthetic reasons. Someone did not like the default outline and deleted it globally.

A word on overlay widgets

There is a category of product that promises compliance from a single line of JavaScript. These are widely criticized by disability advocates, and they have been named in litigation rather than reliably preventing it. They sit on top of the underlying markup instead of correcting it, and they frequently interfere with the assistive technology a person already uses and prefers.

If your site has one installed, the honest advice is to remove it and fix the underlying issues. A procurement officer who knows this field will read an overlay as evidence that nobody addressed the real problem.

What a real audit involves

Automated scanning catches roughly a third of issues. It is genuinely useful for contrast, missing alternative text, and structural problems, and it should be part of any assessment. It cannot tell you whether alternative text is meaningful, whether focus order makes sense, or whether a screen reader user can actually complete a task.

The rest requires a person: keyboard navigation through every flow, testing on actual assistive technology, and evaluating whether the experience is usable rather than merely technically conformant. Anyone selling an automated-only audit is selling part of an audit.

What you should receive is a written report listing each finding, the success criterion it fails, where it occurs, how severe it is, and what the remedy is. It should be actionable by a developer and legible to a stakeholder who is not one.

Where to start if you have not

1. Inventory what you actually have. Websites, mobile apps, documents, video, third party tools, and anything embedded from a vendor.
2. Run an automated scan for a rough picture of scale. Free tools will tell you whether you are facing a handful of issues or several hundred.
3. Get an assessment that includes manual testing. The automated number is not the real number.
4. Prioritize by severity and by traffic. Fix the paths people actually use before the pages nobody visits.
5. Write an accessibility statement and publish it, including how someone reports a barrier.
6. Put procurement language in place so vendors are contractually responsible going forward.
7. Establish monitoring, because sites drift. Every new page and document is an opportunity to regress.

The part worth saying plainly

Compliance deadlines are what get budget approved, and there is nothing wrong with that. But the underlying reason holds regardless of any rule. A meaningful share of the population has a disability, and for a public entity the website is often the only practical way to reach a service, a form, or a meeting. A site that excludes people excludes them from government, not from a brand.

Most of what the standard requires is unglamorous and inexpensive when done during a build. It becomes expensive only when it is retrofitted under a deadline, which is the situation a great many organizations are now in.