# Touch-Friendly Error Message Placement

Where should a validation message go on a phone — below the input as on most desktop designs, above it between label and field, or at the top of the form? And how big must anything tappable inside an error be? Placement decides whether mobile users see errors at all: the virtual keyboard hides the lower half of the screen, thumbs reach the bottom of the screen easily and the top hardly at all, and a message that pushes the next field down makes users mis-tap. This recipe compares placements on the dimensions that matter on touch devices, implements a responsive pattern that moves messages above inputs on small screens without duplicating markup, sizes interactive error content for touch, and keeps every message connected to its field with aria-describedby so it works with the Constraint Validation API and screen readers regardless of where it appears.

# When Placement Needs Rethinking for Touch

Revisit placement whenever a form is used primarily on phones, and especially when:

• Users report “nothing happened” on submit, a sign that messages appear under the keyboard.
• Fields are validated on blur, so errors appear while the keyboard is still open for the next field.
• Messages contain actions — “Did you mean …?”, “Use a different card”, “Remove file” — that need to be tapped.
• Forms are long, so the first error after submit may be far from the submit button.

For the mechanics of scrolling fields and messages above the keyboard, see validating forms with the virtual keyboard open; for the overall mobile approach, the mobile form validation UX topic.

# Minimal Working Responsive Placement

<div class="field">
  <label for="email">Email address</label>
  <p class="hint" id="email-hint">We'll send your receipt here.</p>
  <p class="field-error" id="email-err" hidden></p>
  <input id="email" name="email" type="email" autocomplete="email" required
         aria-describedby="email-hint email-err">
</div>

/* One markup order (label, hint, error, input) serves both layouts.
   Small screens: error sits above the input, visible above the keyboard.
   Large screens: CSS grid moves it below the input for desktop convention. */
.field { display: grid; gap: 0.35rem; }

@media (min-width: 48rem) {
  .field {
    grid-template-areas: "label" "hint" "input" "error";
  }
  .field label { grid-area: label; }
  .field .hint { grid-area: hint; }
  .field input, .field select, .field textarea { grid-area: input; }
  .field .field-error { grid-area: error; }
}

.field-error {
  display: flex;
  gap: 0.4rem;
  align-items: flex-start;
  color: var(--error-text, #b91c1c);
  font-size: 1rem;                  /* readable without zoom */
  line-height: 1.4;
  overflow-wrap: anywhere;          /* long emails wrap instead of overflowing */
}

/* Actions inside errors get touch-sized targets. */
.field-error button, .field-error a {
  min-block-size: 44px;
  min-inline-size: 44px;
  padding-inline: 0.75rem;
}

The DOM order — label, hint, error, input — is the reading order for screen readers on every screen size, so the message is announced before the user reaches the input when swiping, and after the label and hint as part of the description when focusing the input. On wide screens the grid repositions the error visually below the input, where desktop users expect it. WCAG 1.3.2 Meaningful Sequence is satisfied because the visual reordering does not change meaning; test with a screen reader to confirm the result reads naturally in both layouts.

# Placement Option Reference

Toasts deserve a specific warning on mobile: they typically appear at the bottom of the screen, exactly where the keyboard is, and disappear after a few seconds — often before a TalkBack or VoiceOver user reaches them. Field errors belong inline; toasts at most confirm success, as argued in when to use toast vs inline errors.

# Verification Steps

• On a phone, trigger an error on a field near the bottom of the screen: the message is visible with the keyboard open.
• Swipe through the field with VoiceOver or TalkBack: the label, hint and error are read before the input.
• Widen the browser past 48rem: the error moves below the input visually; the reading order is unchanged.
• Tap the “Did you mean” suggestion with a thumb on a small phone: it is easy to hit.
• Trigger an error on a field with an extremely long email: the message wraps without horizontal scrolling at 320px width.

import { test, expect, devices } from "@playwright/test";

test.use({ ...devices["iPhone SE"] });

test("error renders above the input on small screens", async ({ page }) => {
  await page.goto("/details");
  await page.getByLabel("Email address").fill("ada@");
  await page.getByLabel("Email address").blur();
  const err = await page.locator("#email-err").boundingBox();
  const input = await page.getByLabel("Email address").boundingBox();
  expect(err!.y).toBeLessThan(input!.y);
  const suggestion = page.getByRole("button", { name: /Did you mean/ });
  if (await suggestion.count()) expect((await suggestion.boundingBox())!.height).toBeGreaterThanOrEqual(44);
});

# Edge Cases and Failure Modes

Layout shift when a message appears. An error appearing above the input pushes the input down — under the user’s finger if they are about to tap it. Reserve space for one line of error text in each field, as described in reserving space for error messages to prevent layout shift, or show errors only on blur and submit when the user’s finger is not on the field.

Hints and errors competing. Showing both the hint and the error above the input makes the gap between label and field large. Hide the hint while the error is shown if the error repeats the needed information (as most well-written errors do), and keep it referenced in aria-describedby only when visible.

Icons as the only indicator. A small red icon beside the input is easy to miss on a phone and meaningless to screen readers. The text is the indicator; the icon, if any, is decoration.

Summaries that scroll away. An error summary at the top of a long form is out of reach once the user scrolls down to fix the third error. Keep each field’s own message; the summary is an index, not a replacement.

# Typography for Error Text on Small Screens

Error text on phones must be readable at arm’s length and in sunlight. Use the same size as body text — never a smaller “caption” size — because the message is the instruction the user needs most. Keep the colour at 4.5:1 contrast against the background in both themes, prefix the message with an icon only if the text still stands alone, and avoid all-caps or italic styles that reduce legibility. Short sentences wrap better on narrow screens than long ones; “Enter an email like name@example.com” beats a two-clause explanation.

# Thumb Reach and Where Actions Belong

On large phones, the top of the screen is hard to reach with the thumb of the hand holding the device, and the bottom is easy. That affects where error actions belong. Actions that fix a field — apply a suggestion, clear a value — belong next to the field, which will be in the comfortable middle band once it is scrolled into view. Actions that affect the whole form — “Try another payment method”, “Go back and edit” — belong near the primary button at the bottom, not in a banner at the top. And the error summary’s links should scroll each field into the middle of the visible area, not to the very top, where the user would have to stretch to tap into it. These are small decisions, but on a 6.7-inch phone they decide whether a user fixes an error with one hand or gives up.

# Related Guides

• Mobile Form Validation UX — the mobile validation overview.
• Validating Forms with the Virtual Keyboard Open — scrolling messages into view.
• Linking Errors with aria-describedby — keeping placement and association independent.
• Suggesting Email Domain Typo Corrections — the kind of tappable suggestion placed in errors.

← Back to Mobile Form Validation UX