F82: When Visual Formatting Replaces a Phone Number Label

Before WCAG, form design operated largely on a visual assumption: if a field looks like it belongs to a phone number, users will understand it is a phone number. Three boxes, parentheses around the first, a dash between the last two — the pattern was so culturally familiar that labeling felt redundant. WCAG 2.2 Failure F82 (opens in new window) exists precisely because that assumption fails entire categories of users — and because "visually obvious" and "programmatically accessible" are not the same thing.

The Failure

F82 (opens in new window) documents a failure of Success Criterion 3.3.2: Labels or Instructions (opens in new window). The scenario is specific: a web page formats phone number input as three separate fixed-length fields — area code, prefix, extension — surrounded by punctuation characters (, ), and -. The visual layout signals "phone number" to sighted users. No explicit text label identifies the field group.

Here's the problem at the code level. When a screen reader calculates the accessible name for each field, it falls back to the nearest preceding text. With only punctuation as surrounding text, the three fields get labeled — respectively — (, ), and -. That is what gets announced.

<!-- Failure pattern: phone number fields with only punctuation as context -->
<form>
  ( <input type="text" size="3" maxlength="3"> )
  <input type="text" size="3" maxlength="3"> -
  <input type="text" size="4" maxlength="4">
</form>

No field carries meaningful context. A screen reader user hears open-parenthesis, close-parenthesis, dash — three characters that communicate nothing about what data is expected.

Why This Matters

The W3C's description of F82 frames this around users with visual or cognitive disabilities — a pairing that's worth sitting with. Most developers think of screen reader users when they think of labeling failures. But cognitive accessibility is equally at stake here.

For a screen reader user navigating by form fields, the experience is disorienting. Three inputs with punctuation labels provide no instruction about what information to enter, what format is expected, or even that these three fields are related. The user has no way to know they've landed on a phone number form without additional context — and in many implementations, there is none.

For users with cognitive disabilities, the visual pattern itself may not be self-evident. The U.S. convention of (XXX) XXX-XXXX is culturally specific and not universally recognized. International users, users unfamiliar with American phone formatting, or users who process information differently may not decode the punctuation pattern as a phone number prompt. A text label removes the interpretive burden entirely.

Switch users and keyboard navigators face a related problem: without a visible group label, understanding the relationship between three separate inputs requires inferring structure from visual proximity — which assistive technology cannot reliably convey.

This is the gap F82 names directly: authors assume formatting does the work of labeling. It doesn't.

The Fix

The correction is straightforward. A visible text label — "Phone Number" — must identify the set of fields as a group. This satisfies SC 3.3.2 (opens in new window), which requires labels or instructions when user input is required.

<!-- Corrected pattern: explicit label for the phone number group -->
<form>
  <fieldset>
    <legend>Phone Number</legend>
    <label for="area">Area Code</label>
    <input type="text" id="area" name="area" size="3" maxlength="3">
    <label for="prefix">Prefix</label>
    <input type="text" id="prefix" name="prefix" size="3" maxlength="3">
    <label for="line">Line Number</label>
    <input type="text" id="line" name="line" size="4" maxlength="4">
  </fieldset>
</form>

Using <fieldset> and <legend> groups the inputs semantically and provides the screen reader with "Phone Number" as the group context before announcing each individual field. Each <label> element then identifies the specific segment. A screen reader user now hears: "Phone Number group — Area Code — edit text." That's a complete instruction.

Alternatively, if a single input is preferable, a single labeled field accepting a full phone number string eliminates the fragmentation problem entirely:

<label for="phone">Phone Number (e.g., 555-867-5309)</label>
<input type="tel" id="phone" name="phone" autocomplete="tel">

Note the type="tel" attribute — it triggers optimized numeric keyboards on mobile devices — and autocomplete="tel", which supports users who rely on autofill, including many users with motor disabilities and cognitive disabilities who benefit from reduced data entry.

Applying This

F82 is one of the failures that automated testing tools frequently miss. A tool can detect that a field lacks a <label> element, but the punctuation-as-label pattern can sometimes pass automated checks if the tool reads surrounding DOM text as a label candidate. Manual review of every form field group — specifically checking whether the accessible name is meaningful, not merely present — is required.

In code review, the pattern to flag is any set of inputs surrounded only by punctuation or symbolic characters without an explicit <label>, aria-label, aria-labelledby, or <legend>. The question to ask: if you read only the accessible name of each field aloud, does a user know what to enter?

Design-side prevention is also available. Component libraries and design systems should include phone number input patterns with labels built in — not as an afterthought, but as the default. If the pattern requires a label to be accessible, the pattern should ship with the label.

Teams navigating multiple overlapping standards should note that this requirement is not WCAG-exclusive. The underlying obligation — that form inputs be identifiable — appears across Section 508 (opens in new window) and EN 301 549. Our research on standards fragmentation documents how organizations sometimes treat these as separate compliance tracks, when in practice a fix that satisfies WCAG 3.3.2 satisfies the equivalent requirements across frameworks simultaneously.

CORS Perspective

Through a community lens, F82 is a case study in how design assumptions encode exclusion. The phone number formatting convention feels universal to those who grew up with it — but it is culturally specific, visually dependent, and cognitively demanding for users who don't share that reference point. When a development team skips the label because the format "obviously" communicates the field's purpose, they are centering one user experience and treating it as universal. The operational fix is low-cost: a <fieldset>, a <legend>, individual <label> elements. The strategic case is equally clear — phone number fields appear on contact forms, appointment booking systems, healthcare intake screens, and emergency services portals. Inaccessible inputs at those touchpoints don't just frustrate users; they create barriers at moments that matter. Getting this right is a Title II and Title III baseline obligation, not an enhancement.