Contrast (Minimum)
Body text must have a luminance contrast ratio of at least 4.5:1 against its background; large text (≥18pt or ≥14pt bold) needs at least 3:1.
What it requires
Color contrast is the most-violated WCAG criterion on the web — affecting 81% of homepage scans according to WebAIM 2024. Pale-grey body text on white backgrounds, brand colors that look fine to designers but fail the 4.5:1 luminance threshold, and disabled-state buttons that are too dim are the most common failures.
The luminance formula is defined in WCAG and not equivalent to color difference or hue rotation. Tools like WebAIM Contrast Checker and Colour Contrast Analyser compute it correctly.
Common Shopify failure
Default theme colors set to `#999` body text on `#fff`, which yields a 2.85:1 ratio (failing). Brand orange buttons on white that fall to 3.4:1 (passing for large but failing if used on small captions).
How to fix it
Adjust the relevant text or background token until the measured rendered pair meets the required ratio, then re-test affected states and breakpoints. Preserve brand intent where possible, but verify the actual computed colors rather than assuming a fixed percentage change will pass.
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.3 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 pattern that may have a supported suggested fix. 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.3