WCAG 1.4.4: Resize Text

What This Rule Means

WCAG 1.4.4 Resize Text (Level AA) states that text must be resizable up to 200 percent without the use of assistive technology and without loss of content or functionality. In plain terms, when a user zooms their browser to 200% or enlarges the base font size through browser or operating system settings, all text on the page must remain readable and all functionality must remain intact.

The criterion applies broadly to all text rendered on a web page, including body copy, headings, labels, button text, placeholder text inside form fields, navigation links, table content, and captions. It does not apply to text that is part of a logo or brand name, nor to decorative text that conveys no information and is presented purely as image content (such as a scanned photograph of a handwritten note where the text itself is not the accessible content).

A pass requires that at 200% zoom — achieved either through the browser's built-in page zoom (Ctrl/Cmd + plus key or the View > Zoom menu) or through the browser's minimum font size setting — the following conditions hold true: no text is clipped or hidden by its container, no text overlaps other text or interactive elements, no horizontal scrollbar appears at full viewport width (except for content that genuinely requires two-dimensional scrolling such as maps or data tables), and all interactive controls remain operable.

A fail is recorded when fixed pixel values lock text into a size that cannot grow, when containers use fixed heights that clip overflowing text, when viewport meta tags use user-scalable=no or maximum-scale=1.0 to block pinch-to-zoom on mobile, or when JavaScript intercepts zoom gestures to prevent scaling. The criterion is explicitly technology-agnostic: whether the implementation uses CSS, SVG text, or canvas-rendered text, the outcome for the user is what matters. Note that SVG text and canvas-rendered text are inherently difficult to resize and often require additional engineering attention.

Why It Matters

Approximately 2.2 billion people worldwide have some form of vision impairment, according to the World Health Organization. Among these, a very large proportion experience low vision — a condition where vision cannot be fully corrected with glasses or contact lenses but where the person is not fully blind. Low-vision users routinely set their browser zoom to 150%, 200%, or higher, or they configure their operating system to render text at a larger base size. When websites block or break this behavior, these users are entirely excluded from the content.

Beyond diagnosed low vision, situational factors affect virtually every internet user at some point: small screens, bright sunlight, fatigue, aging eyesight, or reading in an unfamiliar language can all make smaller text harder to parse. Older adults in particular — a rapidly growing demographic globally and in Turkey — frequently rely on zoom as a first-line accessibility accommodation before seeking specialized assistive technology.

Consider a concrete scenario: a patient in their sixties is trying to read their online appointment confirmation from a hospital portal on their smartphone. The hospital's mobile stylesheet sets the body font size to 12px using a fixed pixel value and the viewport meta tag includes maximum-scale=1.0. The patient attempts to pinch-zoom but the interface locks. They cannot read the date or the department name clearly enough to be confident. They call the hospital helpdesk, consuming staff time and creating anxiety for the patient — an entirely preventable outcome had the criterion been met.

From a purely commercial standpoint, accessible text sizing correlates with broader usability improvements that benefit all users. Search engines also reward sites that render readable text at normal and enlarged sizes, because Googlebot assesses legibility signals as part of Core Web Vitals and page experience ranking factors. Fixing resize issues therefore simultaneously improves SEO, reduces support burden, and expands the potential audience.

Related Axe-core Rules

WCAG 1.4.4 is primarily a manual testing criterion. Automated tools can flag a narrow set of conditions that are known to prevent text resizing, but they cannot reliably simulate and evaluate all layout outcomes at 200% zoom. The following conditions are what automated tools attempt to detect, and what requires manual follow-up:

• viewport meta tag blocking zoom (manual check required): Axe-core includes the meta-viewport rule, which flags any <meta name='viewport'> tag that sets user-scalable=no or maximum-scale to a value of 1.0 or less. This is the one scenario where a fully automated detection is possible, because the violation is declarative and does not depend on layout outcome. However, even this rule cannot determine whether a site uses JavaScript to programmatically prevent zoom, so manual verification is always needed.
• Fixed font sizes in pixels (manual check required): Automated tools can report when CSS font-size values are set in absolute pixel units (px) rather than relative units (em, rem, %, or viewport-relative units). However, modern browsers override absolute pixel font sizes when the user changes their browser default font size, so a pixel value alone does not constitute a guaranteed failure — it depends on browser behavior and whether the site respects font-size inheritance. Manual inspection of computed styles and visual verification are required to confirm an actual failure.
• Content overflow and clipping at 200% zoom (manual only): No automated tool can reliably render a page at 200% and evaluate whether all text remains visible and all interactive elements remain operable. This requires a human tester to set the browser zoom level, scroll through the page, and verify each content area. Automated tools have no access to the post-zoom rendered state.
• Text in images and canvas (manual only): Text that is baked into raster images (<img> tags containing screenshots of text) or rendered onto a <canvas> element cannot be resized by the browser at all. Automated tools can flag the presence of canvas elements for manual review, but they cannot determine whether those canvas elements contain meaningful text that the user needs to read.

How to Test

1. Run an automated scan first. Open the page in Chrome or Firefox and run axe DevTools (browser extension) or Lighthouse (Chrome DevTools, Lighthouse tab). Look specifically for the meta-viewport rule violation. If flagged, note it as a critical failure. Also check the CSS audit for any font-size declarations in px units that appear in the axe best-practices warnings.
2. Check the viewport meta tag in source. Open DevTools (F12), go to the Elements tab, and search for meta name='viewport'. Read the content attribute carefully. If it contains user-scalable=no, user-scalable=0, or maximum-scale=1 (or any value less than 2), this is a direct failure of 1.4.4.
3. Set browser zoom to 200%. In Chrome or Firefox, press Ctrl + Plus (Windows/Linux) or Cmd + Plus (macOS) repeatedly until the browser zoom indicator reads 200%. Alternatively, go to View > Zoom In. On macOS Safari, use View > Zoom In. Do not use operating system–level display scaling for this test — use browser zoom specifically.
4. Scroll through every page section at 200% zoom. Systematically scroll from top to bottom. Look for: text that is cut off or hidden by its container, text that overflows its box and overlaps adjacent content, form labels that disappear behind their inputs, buttons whose text is truncated, dropdown menus that extend off-screen and cannot be scrolled into view, and modal dialogs that exceed the viewport and cannot be scrolled.
5. Test all interactive functionality at 200% zoom. Activate every navigation menu, open every modal, submit forms, trigger tooltips and popovers, and interact with any carousels or accordions. Verify that all of these remain fully operable — not just visually present.
6. Test with NVDA + Firefox (Windows). Enable NVDA and open Firefox at 200% zoom. Navigate using the Tab key and arrow keys. Confirm that focusable elements receive focus, that focus indicators are visible (WCAG 2.4.7 overlap, but useful to check), and that the reading order matches the visual order at the enlarged size.
7. Test with VoiceOver + Safari (macOS/iOS). Enable VoiceOver. On iOS, go to Settings > Accessibility > Display & Text Size and enable Larger Text. Navigate the same page and verify content integrity. Also use the pinch-to-zoom gesture to confirm it is not blocked.
8. Test browser minimum font size setting. In Firefox, go to Settings > General > Fonts and Colors and set the minimum font size to 24px. Reload the page and verify that all text meets this minimum and that the layout does not break. This tests a different vector of the same criterion.
9. Test with JAWS + Chrome (Windows). Open the page in Chrome at 200% zoom with JAWS active. Use JAWS reading commands (Insert + Down Arrow to read from cursor) to confirm all text content is announced and no content is skipped due to being hidden by overflow clipping.

How to Fix

Viewport meta tag blocking zoom — Incorrect

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Viewport meta tag blocking zoom — Correct

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Fixed pixel font sizes — Incorrect

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Fixed pixel font sizes — Correct

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

Fixed-height containers that clip text — Incorrect

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Fixed-height containers that clip text — Correct

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Text baked into images — Incorrect

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

Text baked into images — Correct

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

Common Mistakes

• Adding user-scalable=no to the viewport meta tag to prevent "layout breaking" on mobile — this is a direct, testable violation of 1.4.4 and must never be used. Fix the layout instead of suppressing the user's ability to zoom.
• Setting maximum-scale=1.0 or any value below 2.0 — even without user-scalable=no, capping zoom at 1.0 or 1.5 prevents users from reaching 200% and fails the criterion.
• Using JavaScript event listeners to call event.preventDefault() on pinch-zoom or wheel events — blocking native zoom programmatically is functionally equivalent to the viewport meta tag approach and fails the same criterion.
• Setting font-size in pixels on the <html> or <body> element and then using em units for everything else — if the root font size is fixed in px, all em/rem descendants are also effectively fixed and will not respond to the user's browser font-size preference.
• Using height instead of min-height on card components, sidebars, or modal bodies — at 200% zoom, enlarged text overflows fixed-height boxes and is clipped by overflow: hidden, hiding critical content.
• Placing important text exclusively inside <canvas> elements — canvas-rendered text is a rasterized bitmap and cannot be scaled by the browser's text resize or zoom mechanisms. Any meaningful text that a user needs to read must be available as real HTML text or at minimum as accessible alternative text.
• Using SVG <text> elements with absolute coordinates and no viewBox scaling — SVG text can be scalable when the SVG uses a viewBox and is sized with relative units, but SVG text with fixed x, y, font-size attributes set in pixels inside an SVG with a fixed width and height does not resize with browser zoom in all browsers.
• Assuming that browser zoom automatically handles the criterion and skipping manual testing — browser zoom scales the entire page including images and layout, but text that was already too small, clipped, or overlapping at 100% becomes a worse problem at 200%. Manual verification at zoom level is always required.
• Forgetting to test third-party embedded widgets — chat widgets, payment iframes, cookie consent banners, and analytics overlays are often developed by third parties using fixed px sizes and may block zoom. Even though the code is third-party, the criterion applies to the whole page as delivered to the user.
• Fixing the desktop layout for zoom but neglecting the mobile breakpoint — many teams test zoom on desktop and declare success, but mobile viewports at 200% zoom present a separate set of layout challenges, especially for navigation menus, sticky headers, and bottom navigation bars that depend on fixed pixel heights.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility requirements for a defined set of organizations operating in Turkey. The circular references internationally recognized accessibility standards — effectively aligning Turkish requirements with WCAG 2.1 and WCAG 2.2 Level AA as the benchmark for conformance.

WCAG 1.4.4 Resize Text is a Level AA criterion, and Level AA conformance is the threshold required to obtain the Accessibility Logo (Erişilebilirlik Logosu) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı). The Accessibility Logo is both a public trust signal and a regulatory checkpoint — organizations subject to the circular that wish to display the logo or demonstrate conformance to auditors must satisfy all Level AA criteria, including 1.4.4.

The categories of entities covered by Presidential Circular 2025/10 include: public institutions and agencies at all levels of government; e-commerce platforms and online marketplaces; banks and financial service providers regulated by the Banking Regulation and Supervision Agency (BDDK); hospitals, health centers, and other healthcare organizations with digital patient-facing services; telecommunications operators with 200,000 or more subscribers; travel agencies and online travel platforms; private transport companies offering digital ticketing or reservation services; and private schools and educational institutions authorized by the Ministry of National Education (Millî Eğitim Bakanlığı, MoNE).

For each of these entity types, the practical implication of 1.4.4 is significant. A bank's online banking portal that blocks pinch-to-zoom on mobile is not just a usability failure — it is a regulatory non-conformance that could result in audit findings or exclusion from the Accessibility Logo program. A hospital appointment booking system that uses fixed pixel font sizes inside clipping containers fails to serve patients with low vision and simultaneously fails its obligations under the circular. A private school's enrollment platform that embeds text in images rather than using scalable HTML text is similarly non-compliant.

Organizations should treat WCAG 1.4.4 not as a narrow technical checkbox but as a baseline expectation of respect for users with visual impairments — an expectation that Turkish law, international best practice, and basic usability all converge upon. Accsible's overlay SDK supports text resizing compliance by providing configurable font scaling controls that allow end users to increase text size independently of browser zoom, offering an additional accommodation layer on top of the baseline requirements that sites themselves must implement.