When Does Page Zoom Become an Accessibility Failure?

## When Does Page Zoom<br>Become an Accessibility Failure?

<p>Steve Jones<br><small>Owner & CTO</small></p>

<p style="margin-top:0px;"><small><a href="https://equalizedigital.com">EqualizeDigital.com</a> | <a href="https://x.com/SteveJonesDev" aria-label="Steve Jones on X">@SteveJonesDev</a></small></p>

WordPress Accessibility Day 2026

Note:
- Aiming for 35–38 min across 37 slides
- Thank the organizers, ~20 sec
- Name and role: accessibility products and services in the WordPress ecosystem

---

## A familiar scene

- You zoom a page to 200%
- The button text gets clipped
- The layout shifts
- Something just looks... off

### <span class="r-fit-text">Is that an accessibility failure?</span>

Note:
- Set stage, pose a quesiton

---

## What we'll cover

1. What WCAG actually requires at 200% and 400% zoom
2. Common misconceptions about zoom testing
3. A practical framework for evaluating zoom issues consistently

Note:
- I'm a developer first, while I make software that audits webistes, I'm not primarily an auditor
- This talk exists because of inconsistent zoom during remediation work 
- I pushed my team to fix inconsistent flagging

---

## Why people zoom

- Low vision, presbyopia, fatigue
- Small or high-resolution screens
- Reading preference: plenty of fully-sighted users zoom too
- It's a **built-in browser feature**, not an edge case

Note:
- Used by far more people than teams assume

---

## Two different things people conflate

**Browser (page) zoom**
Scales everything (text, images, layout) together.

**Text-only resize**
An old browser setting that scaled *only* text, leaving layout untouched.

Note:
- 1.4.4 was written when text-only resize was the norm
- Modern browsers default to full-page zoom
- Some browsers still support an independent text-size bump

---

## Firefox still ships this today

Firefox's **"Zoom Text Only"** setting (View → Zoom → Zoom Text Only) does exactly this:

- Viewport width stays fixed
- Only the text scales: same reflow pressure as a narrow screen

A genuinely different stress test than full-page zoom.

Note:
- Full-page zoom scales everything
- Text-only resize holds width, grows only text
- This triggered this talk

---

## "At least one" mechanism

> Content satisfies the criterion if it can be scaled up to 200% using **at least one** text scaling mechanism supported by user agents.
>
> (WCAG 2.2 Understanding, SC 1.4.4)

Full-page zoom is one mechanism. Text-only resize is another.

Note:
- Real tension, worth sitting with
- Literal reading: passing on full-page zoom alone is technically enough
- Genuine judgment call when text-only mode breaks but zoom passes
- This is the exact ambiguity that caused inconsistent flags on my team
- No single obvious universal answer

---

## Where I landed on this

Inconsistent flagging on my own team pushed me to define a real process:

- Full-page zoom + reflow: the **primary baseline** for every audit
- Text-only resize testing: **supplemental / best practice**, not an automatic AA failure
- Weight it more heavily for AAA and other higher-risk audits
- Severity: best practice, unless it causes **severe loss of content or functionality**

Note:
- Summary: WCAG requires content/functionality preservation, not visual layout preservation

---

## The WCAG landscape

| SC | Level | What it covers |
|---|---|---|
| 1.4.4 Resize Text | AA | Text resizes to 200% without loss |
| 1.4.10 Reflow | AA | Content reflows at 400%-equivalent width |
| 1.4.12 Text Spacing | AA | Content survives user text-spacing overrides |
| 1.4.8 Visual Presentation | AAA | Additional presentation controls |

Note:
- Zoom isn't one SC, it's a cluster people conflate

---

## 1.4.4 Resize Text (AA)

> Text can be resized without assistive technology up to 200% without loss of content or functionality.

- Applies to **text**, but in practice tested via page zoom
- No horizontal scrolling required to read text
- Exception: captions and images of text

Note:
-

---

## 1.4.10 Reflow (AA)

> Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at:
> - 400% zoom, or
> - a viewport width of 320 CSS px (for horizontal reading)

Note:
- Key phrase: "without scrolling in two dimensions"
- Vertical scrolling is always fine
- 1280px design at 400% = 320px viewport: same test, two ways

---

## 1.4.10's exceptions

Content that is *inherently* two-dimensional is exempt:

- Data tables
- Toolbars and menus that require 2D layout to remain usable
- Maps
- Diagrams, images requiring 2D layout to understand

Note:
- Exceptions can get over-applied
- "Table" label alone doesn't grant exemption
- Exception is for genuinely tabular/relational content
- I'll hit this exact case in the pricing-table example later

---

## Misconception #1

### "If it looks broken, it fails WCAG."

- Visual imperfection ≠ accessibility barrier (over-flagging)
- Reflow isn't just about horizontal scrollbars either (under-flagging)

Note:
- Over-flagging: awkward spacing/margins
- Under-flagging: overlap, hidden content, unreachable controls, broken focus
- Both directions are common, and both wrong

---

## Misconception #2

### "400% zoom" always means the same setup.

- 1280px window at 400% zoom → 320px effective width (the SC's actual benchmark)
- 1920px window at 400% zoom → 480px effective width (a false pass waiting to happen)
- Fix: set devtools responsive mode to 320px directly, don't trust the zoom % alone

Note:
- Testing-setup issue, a major source of inconsistent findings

---

## Misconception #3

### "It's a data table, so it's exempt."

- The test isn't "does it look like a table," it's "is the row/column relationship essential to understanding it"
- Exempt: a real data table, where reading across and down together is what gives a number meaning
- Not exempt: a pricing table with independent, self-contained columns just laid out side by side

Note:

---

## So where *is* the line?

Not every zoom quirk is equal.

We need a way to sort:

**Visual imperfection → Usability concern → Accessibility barrier**

Note:
- The 3-tier framework

---

## A 3-tier framework

### Tier 1: Visual imperfection
Looks off, but all content and functionality remain available and usable.
**Not a WCAG failure.**

Note:
- Examples: line breaks, whitespace, icon sizing
- Nothing lost, nothing blocked
- Log this as design polish if at all, Don't cite an SC

---

## A 3-tier framework

### Tier 2: Usability concern
Harder to use, more effortful, but content/functionality technically still reachable.
**Often not a strict SC failure, but flag it.**

Note:
- Example: long line lengths, hard-to-hit controls
- May implicate other SCs (target size) separately
- Gray zone, where professionals disagree and judgment calls are needed

---

## A 3-tier framework

### Tier 3: Accessibility barrier
Content or functionality is **lost, hidden, or unreachable**. Two-dimensional scrolling is required outside a valid exception.
**This is a WCAG failure. Cite the SC.**

Note:
- Examples: clipped text, overlap, blocked controls, forced horizontal scroll

---

## <span class="r-fit-text">Now let's look at real examples</span>

From WordPress audits and remediation projects.

Note:
- Let's walk through real patterns, sorting each one into a framework tier

---

## Example: sticky header overlap

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/01-sticky-header.png" alt="A blue site header overlapping the page heading below it, hiding it from view">
    </div>
  </div>
  <div class="example-text">
    <p>A fixed header stays pinned while the page zooms to 400%.</p>
    <p>Zoomed-in content scrolls <strong>underneath</strong> it and becomes hidden.</p>
    <p><strong>→ Tier 3: Accessibility barrier</strong></p>
  </div>
</div>

Note:
- One of the most common WordPress reflow failures I see
- Content, form fields, or links can end up hidden behind the header
- Content lost from view = clear 1.4.10 failure
- Common with hardcoded header heights in page builders

---

## Example: mega menu

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/02-mega-menu.png" alt="A four-column dropdown menu cut off at the right edge of the viewport, requiring horizontal scroll to see the rest">
    </div>
  </div>
  <div class="example-text">
    <p>A multi-column mega-menu widens instead of stacking at 400% zoom.</p>
    <p>Reading it requires horizontal scrolling to see all columns.</p>
    <p><strong>→ Tier 3: Accessibility barrier</strong></p>
  </div>
</div>

Note:
- collapsible into one stacked column
- Fixable CSS problem

---

## Example: truncated button label

A CTA button has a fixed width. At 200% zoom, "Schedule a Consultation" becomes "Schedule a Con…" and the full label is never revealed.

**→ Tier 3: Accessibility barrier** (1.4.4, content lost)

Note:
- Fixed width + ellipsis is a very common page-builder pattern
- Meaning lost for sighted zoom users if no aria-label / reveal method
- Invisible to automated scanners and screen-reader-only testing

---

## Example: overlapping text

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/04-overlapping-text.png" alt="A large wrapped heading with a blue subheading line overlapping directly through its final line" style="max-height:320px;">
    </div>
  </div>
  <div class="example-text">
    <p>A hero heading and subheading use absolute positioning. At 400%, the subheading slides up and overlaps the heading, and both become unreadable.</p>
    <p><strong>→ Tier 3: Accessibility barrier</strong></p>
  </div>
</div>

Note:
- Absolute positioning + relative font sizing untested past 100%
- Fine for screen readers, unreadable for sighted zoom users
- fragile-CSS

---

## Example: testimonial carousel

A fixed-height carousel slide clips longer testimonial text at 200% zoom: the end of the quote is simply cut off, no scrollbar, no indication more text exists.

**→ Tier 3: Accessibility barrier**

Note:
- Fixed-height containers are a recurring root cause
- Height assumed 100% zoom, never checked with 200 or 400 zoom
- no "read more," no scrollbar

---

## Example: pricing table

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/06-pricing-table.png" alt="Pricing plan cards laid out in a row, with the second card cut off at the right edge of the viewport">
    </div>
  </div>
  <div class="example-text">
    <p>A 4-column pricing table doesn't reflow at 400% and requires horizontal scrolling.</p>
    <p>Client argues: "it's a table, it's exempt."</p>
    <p><strong>Is it?</strong></p>
  </div>
</div>

Note:
- Is the row/column relationship essential, or just a grid design choice?
- Most Pricing tables can stack
- → Tier 3 in most real cases, not exempt

---

## Example: uneven spacing

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/07-uneven-spacing.png" alt="A block of body text with one paragraph's spacing slightly tighter than the others, marked with a gray dashed outline" style="max-width:420px;">
    </div>
  </div>
  <div class="example-text">
    <p>At 200% zoom, paragraph spacing looks slightly inconsistent between sections. Nothing is clipped, nothing is unreachable, everything reads fine.</p>
    <p><strong>→ Tier 1: Visual imperfection</strong></p>
  </div>
</div>

Note:
-

---

## Example: shrinking icon buttons

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/08-icon-buttons.png" alt="A row of four circular icon-only share buttons, shrunk down and marked with an amber dashed outline" style="max-width:380px;">
    </div>
  </div>
  <div class="example-text">
    <p>Icon-only buttons shrink proportionally at 400% zoom. Still tappable, still labeled via aria-label, but now closer to the minimum comfortable target size.</p>
    <p><strong>→ Tier 2: Usability concern</strong> (may separately implicate target size SCs)</p>
  </div>
</div>

Note:
- Gray-zone example: label and function are both still present
- You may need to check against 2.5.8 Target Size separately

---

## Example: text-only zoom overlap

<div class="example-row">
  <div class="example-image">
    <div class="browser-frame">
      <div class="browser-frame-bar"><span></span><span></span><span></span></div>
      <img src="img/09-text-only-zoom.png" alt="A card component where an enlarged heading overlaps the body text below it" style="max-height:260px;">
    </div>
  </div>
  <div class="example-text">
    <p>A card component passes full-page zoom cleanly at 400%. Enable Firefox's <strong>Zoom Text Only</strong> instead: the heading grows, the width doesn't, and it overlaps the card's body text.</p>
    <p><strong>→ Tier 2 or 3</strong>, depending on severity.</p>
  </div>
</div>

Note:
- Callback to the "at least one mechanism" tension
- Technically satisfies 1.4.4 via full-page zoom alone
- Supplemental by default, escalate if illegible, weight higher for AAA/regulated work

---

## Fixing it: flexible sizing over truncation

```css
/* Breaks under zoom */
.btn {
  width: 220px;
  overflow: hidden;
  text-overflow: ellipsis;
}

/* Survives it */
.btn {
  min-width: 220px;
  width: max-content;
  max-width: 100%;
}
```

Note:
-

---

## Fixing it: the grid `em` trick

```css
/* Fixed column count, doesn't respond to text-only zoom */
grid-template-columns: repeat(3, minmax(0, 1fr));

/* Responds because em scales with text size */
grid-template-columns: repeat(auto-fit, minmax(18em, 1fr));
```

Note:
- The fix behind the mega-menu and pricing-table examples
- Grid support alone doesn't guarantee zoom-responsiveness

---

## How to actually test this

1. Zoom the real browser (Ctrl/Cmd + "+"), not just devtools
2. Also verify effective width matches 320px at 400% (check your monitor/window size)
3. Test with keyboard focus moving through the page, not just visually scanning
4. Check both 200% and 400%; they can fail independently
5. Optionally, toggle Firefox's Zoom Text Only as a supplemental check on higher-risk audits

Note:
- Test an actual small-viewport device (phone), not just desktop zoom

---

## Why teams disagree

- I watched this happen on my own team: that's what started this talk
- Inconsistent test setup (monitor size, window width, zoom method)
- No shared vocabulary for "imperfection" vs "barrier"
- No shared policy on which zoom *mechanism* even counts
- Pressure to either over-flag (defensive audits) or under-flag (client relationships)

Note:
-

---

## The framework, recap

**Ask, in order:**

1. Is any content or functionality **lost, hidden, or unreachable**?
2. Is **two-dimensional scrolling** required, outside a valid exception?
3. If neither, is it still harder to use? Log it as usability, not a failure.
4. Otherwise, it's a visual note, not a finding.

Note:
- <em>The payoff of the whole talk</em>

---

## Key takeaways

1. WCAG's zoom requirements are specific: 200% text resize, 400%/320px reflow, and they're testable
2. Most zoom "bugs" trace back to fixed dimensions and absolute positioning
3. The spec is genuinely ambiguous in places. Don't leave that to case-by-case judgment calls; define your own team's standard

Note:
- <em>This closes the loop for the audience</em>

---

## Further reading

- WCAG Understanding: 1.4.4 Resize Text
- WCAG Understanding: 1.4.10 Reflow
- WCAG Understanding: 1.4.12 Text Spacing

Note:
- <em>keep this brief, just citing the doc names</em>

---

## Steve Jones

<p style="margin:4px 0;"><small>Owner & CTO · <a href="https://x.com/SteveJonesDev" aria-label="Steve Jones on X">@SteveJonesDev</a></small></p>

<p style="margin:4px 0; font-size:0.85em;">Meetup: <a href="https://equalizedigital.com/events" aria-label="WordPress Accessibility Meetup">EqualizeDigital.com/events</a><br>
Facebook Group: <a href="https://www.facebook.com/groups/wordpress.accessibility" aria-label="WordPress Accessibility Facebook Group">facebook.com/groups/wordpress.accessibility</a><br>
Podcast: <a href="https://accessibilitycraft.com" aria-label="Accessibility Craft Podcast">AccessibilityCraft.com</a></p>

<p style="margin:4px 0;"><small><a href="https://equalizedigital.com">EqualizeDigital.com</a> | <a href="https://x.com/SteveJonesDev" aria-label="Steve Jones on X">@SteveJonesDev</a></small></p>

Note:
- Thank you organizers
- Hand it off to Q&A