F80: When Form Controls Refuse to Scale With User Text Size

A contact form where the heading scales beautifully but the input fields stay frozen at 12pt. That's the exact pattern WCAG Failure F80 (opens in new window) documents. The surrounding text grows. The labels grow. But the fields where users actually type — and the submit button they need to click — stay locked at whatever absolute size the developer originally set. For a user who has increased their browser text size to 200% to manage low vision, this isn't an inconvenience. It's a barrier to completing the task at all.

F80 is one of those failures worth sitting with for a moment. It raises a question about how accessibility gets implemented in practice: how does a developer correctly scale a heading and a paragraph label, then immediately apply an absolute unit to the <input> right below it? The answer is usually not negligence — it's inconsistency. Different parts of a form often get styled at different times, by different people, following different conventions. The result is a patchwork where some elements respect user preferences and others override them entirely.

The Failure

F80 documents a specific violation of Success Criterion 1.4.4 Resize Text (opens in new window) (Level AA), which requires that text can be resized up to 200% without loss of content or functionality. The failure occurs when text-based form controls — <input> elements, <textarea> elements, and <button> elements — are styled with absolute font size units that don't respond to user-initiated text scaling.

The W3C's example is precise. Here's the problematic CSS pattern:

h1 { font-size: ; }
p, label { font-size: ; }
input { font-size: ; }

The h1 uses em — relative to the parent, scales with user settings. The label uses em — same. But input uses 12pt — an absolute typographic unit that doesn't scale with browser text size preferences. When a user sets their browser to display text at 200%, the heading and labels comply. The input fields don't move.

The accompanying HTML from the W3C document shows a standard contact form:

<h1>Contact Us</h1>
<p>Please provide us with your details and we will contact you as soon as we can.
   Note that all of the form fields are required.</p>
<div>
  <label for="fname">First Name</label>
  <input type="text" name="fname" id="fname">
</div>
<div>
  <label for="lname">Last Name</label>
  <input type="text" name="lname" id="lname">
</div>
<div>
  <label for="phone">Telephone</label>
  <input type="text" name="phone" id="phone">
</div>
<div>
  <label for="email">Email</label>
  <input type="text" name="email" id="email">
</div>
<input type="submit" name="Submit" value="Submit" id="id">

The structure is fine. The labels are properly associated. The failure lives entirely in one CSS declaration.

Why This Matters

For users with low vision who rely on browser zoom or text scaling rather than assistive technology, form fields are exactly where the stakes are highest. Reading a heading at the wrong size is frustrating. Trying to enter — and then verify — an email address or phone number in a field that's still rendering at 12pt while everything around it has doubled? That's where errors happen. That's where users abandon tasks.

The W3C's failure description is direct about this: "the user may have difficulty entering text and being able to read what they have entered because the text is not displayed at the text size required by the user." This isn't about visual preference. It's about functional access to a form's core purpose.

There's also a cognitive dimension. When labels scale and inputs don't, the visual relationship between them breaks down. The label appears at one size; the field it describes appears at another. For users with cognitive disabilities who rely on consistent visual hierarchy to parse a form's structure, this misalignment adds unnecessary processing load.

The submit button is equally affected. An <input type="submit"> with an absolute font size doesn't scale either — meaning the action that completes the entire interaction may be rendered in text the user can't comfortably read.

The Fix

The correction is straightforward: replace absolute units with relative ones.

h1 { font-size: ; }
p, label { font-size: ; }
input { font-size: ; }  /* or 100, or another relative unit */

Using em, rem, or percentage-based font sizes for form controls allows them to inherit and scale with the user's browser text size settings. rem (root em) is particularly useful in design systems because it ties to the document root rather than a potentially complex inheritance chain — making scaling behavior more predictable across components.

This is a one-line fix in most cases. The challenge is finding every instance across a codebase where absolute units have been applied to form controls — especially in legacy CSS, third-party component libraries, or design systems where input styles may be defined in a shared base stylesheet that teams haven't revisited in years.

Applying This

Automated testing tools can detect some instances of this failure — specifically when absolute units appear on form control selectors in CSS — but detection is inconsistent across tools. As our research on automated vs. manual testing documents, automated tools miss significant categories of real-world failures, and F80 sits in a gray zone where tool detection depends heavily on how the CSS is structured and whether the tool evaluates computed styles.

The most reliable catch is a manual check: set browser text size to 200% (in Firefox: View → Zoom → increase text only, not page zoom) and walk through every form on the site. If input fields, textareas, or buttons don't grow with the surrounding text, you have an F80 violation.

For code review, add a linting rule or style guide note flagging pt, px, and cm units on input, textarea, select, and button selectors. This is the kind of convention that's easy to enforce once it's documented — and easy to miss forever if it isn't.

In design systems, the fix belongs at the component level. If your <Input> component's base styles use absolute units, every instance across every product inherits the failure. One correction in the shared stylesheet resolves it everywhere. That's the operational leverage point.

The broader pattern here is worth naming: compliance frameworks often treat WCAG success criteria as a checklist, but failures like F80 reveal how a single CSS property can create a gap between apparent compliance and real access. A form can pass dozens of checks — proper labels, correct ARIA, logical tab order — and still fail a user who needs scaled text to read what they've typed.

CORS Perspective

From a strategic alignment lens, F80 is a compelling case for embedding accessibility requirements directly into design system governance rather than treating them as audit findings. The failure pattern — absolute units on form controls — is almost always a systemic CSS convention, not an isolated mistake. That means the fix is also systemic: one change to a shared stylesheet, one linting rule added to a CI pipeline, one design token updated in a component library. The risk exposure from F80 is real under SC 1.4.4 (opens in new window), but the strategic opportunity is larger — using this specific, fixable failure as the entry point for a broader conversation about how relative units and user-preference-respecting CSS should be the default for all interactive elements, not an afterthought applied after an audit surfaces a violation.