"When we enlarged the text, the button labels overflowed the frame and became unreadable" — we sometimes receive reports like this from corporate clients after launching a redesigned site. Nobody notices it during the design stage because creators view screens at default font sizes. However, on the user side, a substantial number of people increase font sizes in their browser settings or zoom the entire screen to 200% to read. Especially for elderly executives, business partners, and people with low vision, zooming is not a special action; it is how they browse every day.
Zoom resilience is no longer merely a matter of consideration. Under the revised Act on the Elimination of Discrimination against Persons with Disabilities that took effect in April 2024, providing reasonable accommodation to persons with disabilities became mandatory for private businesses as well. A company website that breaks and becomes unreadable when zoomed translates directly into failing to provide reasonable accommodation. Smashing Magazine's Testing Font Scaling For Accessibility With Figma Variables also emphasizes the importance of verifying font scaling resilience starting from the design phase. From our perspective delivering sites in client projects, this is not an issue to be stumbled upon post-launch; it is an item that must be built in as quality from the start.
The real cause of layout breakage on zoom is fixed px values
Websites that break share a common cause: fixing font sizes, margins, and button heights with pixels (px).
The pixel (px) is a unit specifying an absolute number of dots. If you write font-size: 16px, that text remains locked at 16px no matter how a user alters their browser font settings. When a user chooses larger text, the site does not respond, rendering the setting useless. Meanwhile, if button heights are also fixed with height: 40px, any increase in the inner font size causes text to break out past the boundary. The structure itself — cramming expanding text into a rigid box — is the culprit.
Simply switching to relative units completely changes this behavior.
/* 崩れやすい書き方：px で固定 */
.button {
font-size: 16px;
height: 40px;
padding: 0 24px;
}
/* 拡大に耐える書き方：rem と相対的な余白 */
.button {
font-size: 1rem; /* ルートの文字サイズに連動 */
min-height: 2.75rem; /* 固定 height ではなく最低値 */
padding: 0.625rem 1.5rem;
}rem is a unit based on the root element's (html) font size, so when a user increases their browser font size, the entire element scales up proportionally. Likewise, rather than locking button height with height, specifying a minimum with min-height allows the container to expand downward as text grows, preventing overflow. The foundation here extends directly from the concepts covered in our Web Accessibility Guide (GH Media).
Three success criteria to uphold
When discussing zoom resilience, WCAG (Web Content Accessibility Guidelines) success criteria serve as the benchmark. The following three are particularly relevant, each specifying exactly what must not happen.
| Success criterion | Key point | Failure example |
|---|---|---|
| 1.4.4 Resize Text | Content and functionality are preserved even when text is scaled up to 200% | Enlarging text truncates button labels, making them unclickable |
| 1.4.10 Reflow | Content can be read without horizontal scrolling down to a width equivalent to 320px | Zooming triggers horizontal scrollbars, pushing text offscreen |
| 1.4.12 Text Spacing | Text does not overlap when line height, letter spacing, or paragraph spacing are expanded | Increasing line spacing causes text inside cards to overlap and become unreadable |
The second criterion, Reflow, is especially prone to being overlooked in practice. When a user zooms their screen to 200%, the available viewport width is effectively halved. If a layout is constructed on fixed-width assumptions, horizontal scrolling occurs, forcing the user to scroll left and right for every single line of text. That cannot be called readable. Disallowing horizontal overflow and ensuring content reflows vertically is the core requirement here.
The third criterion, Text Spacing, tests resilience against user stylesheets that expand line height and letter spacing. If text is crammed into a fixed height, expanding spacing instantly causes characters to overlap. The cause is identical to fixed px values — an inflexible box — and the solution points in the same direction.
Thinking fluidly rather than relying solely on media queries
When people think of responsive design, the conventional mindset is dividing layouts with @media for screen widths below 768px and switching layouts at that boundary. While effective in itself, it does not handle font scaling well. Because increasing font size does not change window width, the viewport does not cross media query breakpoints, and the layout never switches.
This is where the concept of fluid typography proves effective. By using clamp() to give font sizes a minimum, preferred, and maximum value, text scales smoothly in response to changes in screen and root sizes.
.heading {
/* 最小1.25rem、画面幅に応じて変化、最大2rem */
font-size: clamp(1.25rem, 1rem + 2vw, 2rem);
}Rather than switching abruptly with "all screens below 768px," changing sizes continuously makes layouts far more resilient across zoom levels and intermediate screen widths. Sudden visual jarring at breakpoints is also minimized. Concurrently, specifying margins and container widths relatively using %, rem, or container queries allows the entire layout to adapt naturally as text grows. Because trade-offs with rendering performance can arise, evaluating this alongside perspectives in Core Web Vitals (GH Media) ensures a safe implementation.
Verifying zoomed states during the design phase
Catching layout breaks after launch is the worst possible timing. Fixing them requires code rework, and by then you have already lost users. That is why verifying zoomed states during the design phase is so valuable.
The Smashing Magazine article cited earlier introduces a method for incorporating this verification into the design workflow using Figma Variables. By defining baseline font sizes as variables and creating modes that toggle values to 125%, 150%, and 200%, designers can immediately verify on design files whether a button label will overflow when enlarged. Potential breakages can be eliminated before writing implementation code or testing in a browser.
In our client web development work, we integrate this as a formal step in our review process. As a concrete example, when building a website for a professional services firm, we inspected all screens for application buttons and pricing cards under a 200% font mode. As a result, we identified two issues prior to implementation: pricing table numbers overflowing cells when enlarged, and fixed-height CTA buttons cutting off the bottom line when text wrapped to two lines. Both were resolved by converting to min-height and relative padding, resulting in zero rework after launch. The need for similar considerations around forms and user flows directly connects with Inclusive UX Design for Cognitive Diversity in Custom Projects (GH Media).
Common layout breakages and how to fix them
Finally, here is a summary of layout breakages that frequently occur during zoom, organized by cause and remedy. All share the same root cause: stuffing content into rigid containers.
- Button text overflows or is cut off: Stop fixing height with
height; switch tomin-heightand relative padding so the container expands downward if text wraps to two lines. - Horizontal scrollbar appears on zoom: Replace fixed px widths with
max-widthand%/rem, and applymax-width: 100%to images and tables. - Navigation disappears offscreen: Avoid rigid horizontal arrangements; allow items to reflow into vertical stacks or collapsed menus at narrow widths.
- Text overlaps when line height increases: Specify
line-heightas a unitless number and avoid fixed container heights.
Once codified into a checklist and built into the production pipeline, these quality checks can be reproduced across every project. Other accessibility considerations, such as timeouts and color palettes, can be systematized similarly. For instance, managing automatic logouts is covered in Session Timeout Accessibility (GH Media), and color contrast is detailed in Accessible Color Palettes with CSS contrast-color (GH Media).
Guaranteeing zoom resilience as quality in custom development
Supporting font scaling and zoom is not about adding exotic features. It means abandoning fixed px values in favor of relative units, avoiding cramming content into fixed heights, and ensuring that zoomed states are inspected during both design and post-implementation phases. Having these standard practices built into the process is what separates sites that break after launch from sites that remain readable no matter who zooms in.
If you are concerned about whether your website breaks when zoomed, or if you want to ensure accessibility quality alongside a redesign, we can undertake standalone zoom resilience audits for existing sites. Starting with an initial inspection is welcome. Please feel free to reach out via our contact page.
Sources
- Smashing Magazine「Testing Font Scaling For Accessibility With Figma Variables」 https://www.smashingmagazine.com/2026/03/testing-font-scaling-accessibility-figma-variables/
- Web Accessibility Guide (GH Media)
- Inclusive UX Design for Cognitive Diversity in Custom Projects (GH Media)
- Session Timeout Accessibility (GH Media)
- Accessible Color Palettes with CSS contrast-color (GH Media)
- Core Web Vitals（GH Media）
