← All criteria
1.4.4Level AAWCAG 2.0Guided or hands-on fix

Resize Text

Except for captions and images of text, text must be resizable up to 200% without loss of content or functionality.

What it requires

Users with low vision rely on browser zoom (Ctrl/Cmd +) and per-element text resize. WCAG 2.0 SC 1.4.4 requires every page to remain usable when text is resized to 200% — no clipped content, no horizontal scrolling on body text, no broken layout, no buttons with overflowing labels.

The most reliable way to satisfy 1.4.4 is to size text with relative units (`rem`, `em`, `%`) rather than absolute pixels, and to use `max-width` on containers instead of fixed widths.

Common Shopify failure

Hero copy set in `font-size: 18px` and absolute-positioned over a fixed-height background image — at 200% zoom the copy overflows the image and gets clipped. Sticky announcement bar set to `height: 36px` with no overflow handling.

How to fix it

Use flexible sizing and containers that can grow, then test at 200% text size. Converting units mechanically is not sufficient when fixed heights, overflow rules, or positioned content still clip text.

Merchant QA checklist

  • Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
  • Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 1.4.4 failure after a theme edit.
  • Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.

How AccessComply handles it

AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a guided or hands-on fix pattern. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.

Primary source: W3C — WCAG 2.0 Understanding 1.4.4