Zooming text to 200 percent under the ADA

Zooming to 200 percent

Except for captions and images of text, text must be resizable up to 200 percent without assistive technology and without loss of content or functionality. In plain terms: a visitor who zooms the browser, or raises the text size in their settings, must still be able to read everything and use every control.

"Without assistive technology" means the standard browser zoom or text-size setting, not a screen magnifier. "Loss" means text clipped by a container, buttons that overlap, menus that become unreachable, or content hidden behind a fixed bar.

Content or controls drawn by the browser or platform, such as a native file picker or a browser tooltip, are not the author's responsibility under this criterion.

Where public pages break at 200 percent

Residents with low vision routinely zoom service pages: a school district enrollment form, a court e-filing screen, a library account page. The failures that show up are mechanical. Form fields stay tiny while their labels grow. A fixed header takes up half the window and covers the field being edited. A pixel-sized container clips a deadline.

Because these tasks often have a deadline attached, a page that cannot be used when zoomed is a real barrier, not a cosmetic annoyance.

Form fields that do not grow with the text

Text inputs should grow with the text size. Size them in relative units and give them room.

.enroll-form input {
  width: 120px;
  height: 24px;
  font-size: 11px;
}

.enroll-form input {
  width: 100%;
  max-width: 14rem;
  min-height: 2.5rem;
  padding: 0.5rem 0.75rem;
  font-size: 1rem;
}

Fixed headers that swallow the screen

A fixed header measured in pixels looks fine at 100 percent. At 200 percent, with a narrower effective viewport, the header wraps and covers the content under it.

.filing-header { position: fixed; top: 0; height: 80px; }
main { margin-top: 80px; }

.filing-header { position: sticky; top: 0; }
/* height comes from content, so it wraps and the page flow adjusts */

Font sizes tied only to the viewport

Sizing text only in viewport units means browser zoom may not change it at all, which fails this criterion. Combine a relative unit with any fluid part.

.page-title { font-size: 2.2vw; }

.page-title { font-size: calc(1.25rem + 1vw); }

System text size in native apps

Native apps usually get this by using the platform's text styles. Avoid fixed point sizes and fixed-height containers.

// SwiftUI
Text("Pay by May 1").font(.system(size: 14))

// SwiftUI
Text("Pay by May 1").font(.callout)   // follows Dynamic Type

// Jetpack Compose
Text("Pay by May 1",
     fontSize = with(LocalDensity.current) { 14.dp.toSp() })  // cancels font scale

// Jetpack Compose
Text("Pay by May 1", fontSize = 14.sp)  // sp follows the user's font size

A test routine

1. Set the browser to 200 percent (Ctrl and + or Cmd and +) on a desktop-size window. Walk through every task in the page.
2. In Firefox, also try View, Zoom, Zoom Text Only, because some failures only show when text grows and the layout does not.
3. Look for clipping, overlap, hidden controls and a fixed header that covers fields.
4. On a phone, raise the system font size to the maximum and repeat for web pages and apps.
5. Confirm that the viewport meta tag does not block zoom.

Common mistakes and a ship-it list

• user-scalable=no or a low maximum-scale in the viewport tag.
• Containers with a fixed height and overflow: hidden around text.
• A custom text-size widget that stops at 150 percent.
• Testing only with a layout that switches to mobile at 200 percent and assuming that is enough; check that everything is still present there.

Ship it when:

• All text, controls and messages are usable at 200 percent.
• No clipping, overlap or fixed bar blocks the task.
• Pinch zoom is allowed on mobile web.
• Native screens follow the system font size.

This criterion pairs well with the reflow criterion. For the legal background, see WCAG 2.1 AA and the ADA.

Sources

• Understanding SC 1.4.4: Resize Text (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.