ADA Title II and Automated Accessibility Checks

Overview

ADA Title II addresses a precise public-system problem: people with disabilities must be able to use state and local government web content and mobile apps when those digital channels provide programs, activities, or benefits. The U.S. Department of Justice final rule published in 2024 amends 28 CFR part 35 and requires conformance to WCAG 2.1 Level AA for covered web content and mobile apps, subject to enumerated exceptions. A measurement of 44 state portals therefore cannot answer “is this state compliant” by itself. It can answer a narrower engineering question: which machine-detectable barriers are visible on sampled public pages at a documented time, tool version, viewport, and authentication state.

The limit matters because WCAG conformance is not a static page property that can be fully inferred from markup. Some success criteria are syntactic enough for automated detection, such as missing form labels or invalid ARIA references. Others require human judgment, task execution, or assistive-technology behavior, such as whether link text identifies purpose, whether focus order preserves meaning, or whether an image’s text alternative is equivalent. The practical problem solved by automated checks across 44 portals is prioritization and repeatability, not final legal adjudication. The output is a defect inventory with known blind spots.

How it works

At the systems level, an automated accessibility check is a browser-mediated inspection pipeline. A crawler or scripted runner opens a URL, waits for a defined load state, and inspects the Document Object Model, computed styles from the CSS Object Model, ARIA attributes, form relationships, headings, landmarks, images, links, and sometimes color pairs. Modern test harnesses commonly use W3C WebDriver or browser automation protocols to execute the page as a browser does, rather than parsing static HTML alone. That distinction matters for state portals because navigation menus, alert banners, search controls, and language widgets are often hydrated by client-side scripts.

The checker then maps observed conditions to rules derived from WCAG success criteria, WAI-ARIA 1.2, HTML, the Accessible Name and Description Computation 1.2, HTML Accessibility API Mappings, and Core Accessibility API Mappings. For example, an input without an associated accessible name can be detected by applying the accessible-name computation; an element with aria-labelledby that references a missing id can be detected from the DOM; a foreground/background color pair can be compared against WCAG contrast thresholds when both colors are computable. The browser’s accessibility tree is relevant because assistive technologies consume platform accessibility APIs, not raw HTML.

For a 44-portal measurement, the defensible unit of evidence is the reproducible observation, not a score. A correct report records the URL set, timestamp, user agent, viewport, script-disabled or script-enabled state, authentication state, rule engine version, and whether pages were public, archived, transactional, or document downloads. Without those fields, two measurements can disagree for reasons unrelated to accessibility: a portal may serve different markup by viewport, language, geolocation, content-delivery configuration, or feature flag.

What 44 state portals deliver

Applying the narrowest possible version of that method — one HTTPS GET per homepage, delivered HTML only, no JavaScript executed — across all 50 state portals plus the District of Columbia returned 44 measurable documents on 26 July 2026. Seven were not measurable: five answered HTTP 403 to an automated request, one redirected to a bot-validation interstitial, and one returned HTTP 502. Every one of the 44 declared a document language and a viewport. Past that point the set separates. 39 of 44 exposed a main landmark, 30 of 44 shipped a skip link, 26 of 44 delivered exactly one first-level heading and 8 of 44 delivered none; 10 of the 44 passed all five structural checks at once. Median time to first byte was 386 ms, 33 of 44 negotiated HTTP/2 or HTTP/3, 36 of 44 compressed the document and 29 of 44 sent HSTS. On the privacy dimension the median document declared 11.5 third-party registrable domains, 36 of 44 referenced at least one analytics or tracking origin, 21 of 44 set a cookie before any interaction, and exactly one surfaced a recognisable consent-management signal.

Those numbers are a floor, not a verdict, and the distance between the two is the point. No JavaScript ran, so any markup a portal builds on the client is invisible here. None of the five structural checks is itself a WCAG success criterion: a declared document language maps to SC 3.1.1, and a skip link or a set of landmarks can satisfy SC 2.4.1 Bypass Blocks, but WCAG does not require exactly one first-level heading, and the presence of a viewport declaration says nothing about whether zoom is suppressed. Image text-alternative coverage is recorded as the share of img elements carrying a non-empty alt value, which counts a correctly empty alt on a decorative image as missing — so the median of 89 per cent is a lower bound on attribute presence, not a defect rate. Time to first byte is a single cold observation from one vantage point. A portal could clear all five checks and still fail Level AA on contrast, focus order or error recovery, and a portal could miss several and still conform once rendered.

What the standard says

The current DOJ Title II web rule uses WCAG 2.1 Level AA as the technical standard. The 2024 final rule set compliance dates of April 24, 2026 for public entities with a total population of 50,000 or more, and April 26, 2027 for public entities with a total population of less than 50,000 and for special district governments. An interim final rule published April 20, 2026 extended both dates: entities with a total population of 50,000 or more now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028. That extension moved the dates only — it left the WCAG 2.1 Level AA technical standard in place. WCAG 2.2 is the current W3C Recommendation, but the DOJ rule specifically incorporates WCAG 2.1. WCAG 2.0 remains important because the Revised Section 508 standards incorporated it, but it is not the Title II web-rule target named in the 2024 DOJ rule.

WCAG 2.1 is organized by principles, guidelines, testable success criteria, and conformance requirements. At Level AA, documented thresholds include Success Criterion 1.4.3 Contrast (Minimum), requiring at least 4.5:1 contrast for normal text and 3:1 for large-scale text; Success Criterion 1.4.11 Non-text Contrast, requiring at least 3:1 for visual information needed to identify user-interface components and graphical objects; and Success Criterion 1.4.10 Reflow, requiring content to be presented without loss of information or functionality and without two-dimensional scrolling at 320 CSS pixels width or 256 CSS pixels height, except for specified content types.

The rule also contains exceptions that change the measurement boundary. The DOJ rule identifies exceptions for archived web content, preexisting conventional electronic documents, certain third-party content, individualized password-protected conventional electronic documents, and preexisting social media posts. These exceptions do not mean that inaccessible content is technically accessible; they define when the regulatory requirement does not apply in the same way. A portal audit therefore needs classification metadata before conclusions are drawn from an automated finding on a PDF, archive page, embedded third-party widget, or authenticated record.

Trade-offs

The measurable advantage of automation is coverage per unit time and reproducibility. A rules engine can scan many pages, detect recurring template defects, and produce stable evidence for issues such as missing alt attributes, duplicate ids, empty buttons, unlabeled inputs, invalid ARIA roles, insufficient computed contrast, missing document language, or heading-order anomalies. In a 44-portal sample, this is useful because state portals frequently share content-management templates across many pages. One defect in a header, search form, emergency banner, or footer can propagate broadly.

The measurable disadvantage is incomplete criterion coverage and false certainty. Automated tools can determine that an img element lacks an alt attribute, but they cannot determine in general whether an existing alt value communicates the same purpose as the image. They can identify that a button has an accessible name, but not whether “read more” is meaningful in context for every repeated card. They can flag no keyboard event handler in obvious cases, but they cannot prove that a multistep transaction has no keyboard trap without executing the task path. The result is an asymmetric evidence model: positive automated findings are often actionable, while absence of findings is not evidence of conformance.

There is also a measurement trade-off between page sampling and task sampling. Portal home pages expose high-traffic navigation and global templates, but Title II programs often live in workflows: filing forms, locating benefits, scheduling appointments, paying fees, reading notices, or downloading records. WCAG conformance applies to web content, but user impact is often task-shaped. A minimal measurement of 44 portals should therefore separate “public landing-page defects” from “program workflow defects,” because those are different risk surfaces and require different diagnostic methods.

Failure modes

Common state-portal failure modes are diagnosable from specific standards. Missing accessible names on form controls are diagnosed through HTML label mechanisms and the Accessible Name and Description Computation. ARIA misuse is diagnosed against WAI-ARIA 1.2, including prohibited roles, missing required owned elements, and references to nonexistent ids. Contrast failures are diagnosed against WCAG 2.1 SC 1.4.3 or 1.4.11 using computed foreground and background colors. Reflow failures are diagnosed by setting the viewport to the documented 320 CSS-pixel width threshold and checking for loss of information or two-dimensional scrolling, subject to the criterion’s exceptions.

Other failures require structured human review. SC 2.4.3 Focus Order requires that focusable components receive focus in an order that preserves meaning and operability. A tool can list tab order, but a reviewer must decide whether the order is meaningful. SC 2.4.4 Link Purpose (In Context) requires the purpose of each link to be determined from link text alone or its programmatically determined context. SC 3.3.1 Error Identification and SC 3.3.3 Error Suggestion require observing validation behavior, submitted states, and recovery guidance. Captions, audio description, plain-language adequacy, and equivalence of alternatives similarly exceed pure DOM inspection.

Diagnosis should distinguish source defects from rendered defects. A missing label may originate in a content-management field, a shared component library, a translation layer, or a client-side hydration failure. A contrast failure may appear only after a seasonal theme, emergency alert, or hover state is applied. A focus trap may occur only when a modal dialog, cookie banner, map overlay, or mobile menu is open. Recording the DOM state, accessibility tree snapshot where available, screenshot, viewport, input modality, and reproduction steps is more useful than recording only a rule id.

A minimal implementation

A correct minimal implementation for measuring 44 portals begins with a manifest, not a scanner. The manifest lists each portal URL, page type, inclusion reason, timestamp, and whether the content is public, authenticated, archived, a conventional electronic document, third-party content, or social-media content. The test environment fixes user agent, viewport set, language preference, script state, and network assumptions. The automated pass then runs rules tied to WCAG 2.1 AA and related platform specifications, while preserving raw artifacts: HTML snapshot after rendering, screenshots, console errors, rule-engine version, and computed issue locations.

The manual pass should be smaller but criterion-driven. It should include keyboard-only navigation; visible focus inspection under WCAG 2.1 SC 2.4.7; focus order under SC 2.4.3; bypass mechanisms under SC 2.4.1; form error identification under SC 3.3.1; link purpose under SC 2.4.4; name, role, value under SC 4.1.2; and selected reflow and zoom checks. For documents, PDF/UA can inform technical inspection, but the Title II web rule’s named accessibility target remains WCAG 2.1 Level AA for covered web content and mobile apps.

The minimal output is a conformance-oriented defect ledger rather than a grade. Each record should contain the portal, URL, component, WCAG success criterion, normative source, detection method, reproduction steps, observed evidence, affected modality, and whether human judgment is required. Findings should be grouped by shared component where possible, because fixing a template defect is materially different from editing a single page. The final interpretation should state the known limitation plainly: automated checks identify many detectable barriers across the 44 portals, but Title II accessibility depends on the full covered content, workflows, exceptions, and WCAG 2.1 AA conformance, including criteria that machines cannot fully judge.