2026-05-17 · 5 min read

WCAG 2.1 Mobile Accessibility for Government Websites: What the DOJ Rule Requires

# WCAG 2.1 Mobile Accessibility for Government Websites: What the DOJ Rule Requires

Government IT teams typically test accessibility on a desktop browser with a keyboard. That catches a real subset of failures. It does not catch the failures that only appear on a phone.

The DOJ Title II Final Rule covers mobile apps alongside websites, and WCAG 2.1 — the specific standard the rule requires — was deliberately expanded from WCAG 2.0 to address mobile use patterns. Several of the new Level AA success criteria exist specifically because touchscreen interaction creates accessibility problems that desktop browser testing cannot reveal.

This post explains what the mobile-specific criteria require and where government sites most commonly fail them.

The Rule Covers Mobile Explicitly

The DOJ's own fact sheet on the Title II Final Rule states: "State and local governments must make sure that their web content and mobile apps meet WCAG 2.1, Level AA."

This means:

• Your public-facing website, tested on a mobile browser
• Any native app your agency distributes (transit apps, parking apps, permit trackers, 311 apps)
• Any web content that residents access on a phone — which is the majority of non-work internet use in most demographics

If your agency has a native iOS or Android app, that app must meet WCAG 2.1 Level AA by April 2027. The same deadline. The same standard.

What WCAG 2.1 Added for Mobile

WCAG 2.1 introduced 17 new success criteria beyond WCAG 2.0. Several were written specifically to address mobile interaction patterns. Here are the ones most relevant to government sites:

1.3.4 Orientation (Level AA)

Content must not lock itself to portrait or landscape mode unless a specific orientation is essential to the function.

The failure this addresses: mobile apps and mobile web pages that force portrait-only display. Users who mount their phones in landscape orientation — including many wheelchair users whose phones are mounted to their chairs — cannot use content that refuses to rotate.

Government sites commonly fail this on:

• Embedded map widgets
• PDF viewers rendered inline
• Custom video players
• Mobile-specific form pages built with a fixed viewport

Test: Rotate your phone. Does the layout rotate? If it stays portrait-locked on a page that doesn't require portrait layout, that's a failure.

1.3.5 Identify Input Purpose (Level AA)

Forms must identify the purpose of inputs that collect personal information — name, email, phone, address, payment info — using autocomplete attributes that browsers and assistive technology can recognize.

The purpose: users with cognitive disabilities, motor impairments, or anyone who benefits from autofill can complete forms without re-entering data they've previously provided to their browser. Screen reader users also benefit because the purpose of a field is announced, not just its label.

Government forms — permit applications, service requests, contact forms — commonly collect exactly this information and commonly omit the autocomplete attributes.

Test: Open your browser's developer tools. Find a form input collecting an email address. Check for autocomplete="email". Find one collecting a first name. Check for autocomplete="given-name". Missing or generic autocomplete="on" is a failure.

2.5.1 Pointer Gestures (Level A)

Any functionality that requires a multi-point gesture (pinch-to-zoom, two-finger swipe) or a path-based gesture (draw a shape, swipe in a specific direction) must also be operable with a single pointer — a single tap or click — unless the multi-point gesture is essential.

Government sites rarely have functionality that inherently requires multi-touch gestures, but custom map implementations, image galleries, and embedded interactive visualizations sometimes do.

Test: Can every action on the page be completed with a single tap? If pinching to zoom a map is the only way to interact with it, that's a failure.

2.5.3 Label in Name (Level A)

For interactive controls that have a visible text label, the accessible name (what screen readers announce) must contain the visible text label.

The failure: a button that visually displays "Submit Application" but whose accessible name has been overridden to say something different — often by a poorly-implemented ARIA label. Screen reader users who activate controls by voice input use the visible label text to trigger the control. If the accessible name doesn't match, voice control fails.

Test: Use a browser accessibility inspector (Chrome DevTools, Firefox Accessibility, axe DevTools) to check the accessible name of buttons and links. Compare it to the visible label text.

1.4.10 Reflow (Level AA)

Content must reflow to a single column when viewed at 320 CSS pixels wide without requiring horizontal scrolling. This criterion is about responsive design — content that requires horizontal scrolling at 320px wide fails.

320 CSS pixels at 400% zoom is a proxy for low-vision users who zoom their browser significantly. Government sites with fixed-width tables, non-responsive data grids, or content embedded in fixed-width containers commonly fail reflow.

Test: In your browser, zoom to 400% on a desktop browser. Does any content require horizontal scrolling to read?

Where Government Sites Most Commonly Fail Mobile Testing

From auditing Florida government sites, these are the most common mobile-specific failures:

Meeting agendas and minutes served as inline PDF viewers. The embedded viewer often fails orientation lock, reflow, and keyboard access simultaneously.

Service request forms with fixed viewport declarations. <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"> — the maximum-scale=1 prevents users from zooming. This fails WCAG 1.4.4 (Resize Text) and is a common pattern on mobile-optimized government forms.

GIS map embeds. Most embedded mapping widgets rely on multi-touch gestures for zooming and panning. Single-pointer alternatives are rarely provided. This fails 2.5.1.

Navigation menus that rely on hover states. Mobile browsers have no hover state. If a navigation menu is only accessible via hover on desktop, mobile users may not be able to access it at all.

Touch target sizes. Buttons and links with tap targets smaller than 44×44 CSS pixels are difficult for users with motor impairments. This is WCAG 2.5.5, which is Level AAA — not a strict Title II requirement — but it appears in DOJ enforcement guidance as a usability concern and is worth fixing regardless.

Mobile Testing Methodology

You cannot assess mobile accessibility from a desktop browser alone. A credible mobile accessibility review requires:

1. Responsive testing at 320px, 375px, 414px widths using browser dev tools 2. iOS VoiceOver testing with a physical iPhone — VoiceOver interacts with native gesture handling that desktop browser simulation doesn't replicate 3. Orientation testing — rotate the device through portrait and landscape on each page type 4. Zoom testing — test at 200% and 400% browser zoom for reflow compliance 5. Autocomplete attribute audit — check forms for proper input purpose identification

The Parallax WCAG audit from Morton Technology Consulting includes mobile accessibility review as a component of the full 200-page site assessment — covering orientation, reflow, input purpose, and VoiceOver testing alongside the full desktop and keyboard accessibility review.

If you are building an internal mobile testing baseline, the WCAG Pre-Audit Readiness Kit ($149) includes a mobile-specific testing checklist covering WCAG 2.1's mobile criteria, a browser zoom test procedure, and a viewport declaration audit guide.

---

*Morton Technology Consulting LLC, Tallahassee, FL. WCAG 2.1 AA audits for Florida government agencies — desktop, mobile, and document. [email protected]*

Morton Technology Consulting LLC — WCAG 2.1 AA audits for Florida government agencies. Parallax audit → · WCAG Readiness Kit → · All posts →