Zoom and Text Resizing

Web browsers give users two main ways to make text bigger: page zoom (which scales everything proportionally) and text-only resizing (which increases font sizes while leaving other dimensions unchanged). WCAG Success Criterion 1.4.4 (Resize Text) requires that text can be resized up to 200% without loss of content or functionality, and without requiring assistive technology beyond the browser's built-in controls. A separate criterion, 1.4.10 (Reflow), extends this idea by requiring content to reflow into a single column at 400% zoom without horizontal scrolling.

Many users rely on zoom or enlarged text every day. People with low vision may set their browser's minimum font size to 24px or higher. Others zoom the entire page to 150% or 200% as a baseline. When a site breaks under these conditions, the content becomes inaccessible to a large group of users who have no other practical option.

Why zoom and text resizing matters

Approximately one in four adults reports some form of vision difficulty. Not all of them use screen readers; many simply need bigger text. When developers lock font sizes in pixels, clip overflow with overflow: hidden on containers that hold text, or use fixed-width layouts that cannot reflow, these users encounter overlapping text, hidden content, or horizontal scroll bars that make navigation painful.

WCAG 1.4.4 is a Level AA requirement, which means it falls within the baseline that most accessibility policies and regulations expect. Failing it can create legal exposure and, more practically, drives away users who cannot read the content.

Beyond low vision, zoom and text resizing also affects users with cognitive disabilities who find larger text easier to process, users on high-DPI mobile devices who pinch-to-zoom, and older adults whose near vision has changed with age.

How zoom and text resizing works

Browser zoom vs. text-only resize

Browser zoom (Ctrl/Cmd + Plus) scales the entire viewport, including images, padding, and borders. The layout engine treats the viewport as if the screen were physically smaller. Text-only resize (available in browser settings or via accessibility preferences) increases only font sizes. Both must be supported.

Text-only resize is the harder case. If a container has a fixed height in pixels and the text inside it grows, the text will overflow. If overflow: hidden is set, the overflowed text disappears entirely.

Using relative units

The single most effective technique is to size text with relative units (em, rem, or %) instead of px. When the root font size changes (because the user adjusted it), every element sized in rem scales with it. Elements sized in px do not.

Layout dimensions that constrain text should also use relative units or be allowed to grow. A max-width in ch or em units, for example, expands as font size increases.

Viewport meta tag

On mobile browsers, the viewport meta tag controls whether pinch-to-zoom is allowed. Setting user-scalable=no or maximum-scale=1.0 disables zoom entirely, which directly violates WCAG 1.4.4.

Media queries and reflow

At high zoom levels, the effective viewport width shrinks. A page zoomed to 400% on a 1280px-wide screen behaves like a 320px-wide viewport. Responsive breakpoints that adapt the layout for narrow screens therefore serve double duty: they also handle high zoom. This is the connection between zoom support and content reflow (WCAG 1.4.10).

Code examples

Bad: fixed pixel sizes and disabled zoom

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

<style>
  .card {
    width: 300px;
    height: 150px;
    overflow: hidden;
    font-size: 14px;
  }
</style>

<div class="card">
  <h2>Latest news</h2>
  <p>This text will be clipped if the user enlarges their default font size,
     because the container has a fixed pixel height and hidden overflow.</p>
</div>

This example has three problems. The viewport tag blocks pinch-to-zoom. The container's height is fixed in pixels, so enlarged text overflows and gets clipped. The font size is set in px, so it ignores the user's text size preference.

Good: relative units and zoom-friendly viewport

<meta name="viewport" content="width=device-width, initial-scale=1.0">

<style>
  html {
    font-size: 100%; /* respects browser default, usually 16px */
  }

  .card {
    max-width: 40ch;
    padding: 1em;
    font-size: 1rem;
  }

  .card h2 {
    font-size: 1.25rem;
  }

  .card p {
    font-size: 1rem;
    line-height: 1.5;
  }
</style>

<div class="card">
  <h2>Latest news</h2>
  <p>This text reflows naturally when the user zooms or increases their
     default font size. The container grows with the content.</p>
</div>

The viewport tag no longer restricts scaling. The .card container has no fixed height, so it expands as text grows. All font sizes use rem, which tracks the user's root font size preference. The max-width is set in ch units, so the line length stays comfortable at any scale.

Bad: clipping navigation at zoom

<style>
  nav {
    height: 48px;
    overflow: hidden;
    white-space: nowrap;
  }
</style>

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

At 200% zoom or larger text, the links may wrap or grow taller than 48px, and overflow: hidden will hide some of them.

Good: flexible navigation

<style>
  nav {
    display: flex;
    flex-wrap: wrap;
    gap: 0.5em;
    padding: 0.5em;
  }

  nav a {
    font-size: 1rem;
    padding: 0.5em 0.75em;
  }
</style>

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

With flex-wrap: wrap, the links move to a new row when space runs out. No content is hidden, regardless of zoom level or text size.

Testing tips

To verify zoom and text resizing support, test at least two scenarios: set the browser zoom to 200% and confirm no content is lost or overlapped, then change the browser's default font size to "Very Large" (or equivalent) and reload the page. In both cases, all text should be readable, all interactive controls should be operable, and no horizontal scrollbar should appear on a standard desktop viewport width. Browser DevTools can simulate narrow viewports to approximate high zoom conditions quickly.