Beware of the Leopard — Part 2: Listening to the answer

Listening to the answers

Part 1 covered asking the right questions. Labels, types, autocomplete, grouping. Your form now knows how to ask the right things, the right way.

But a conversation isn't an interrogation. Asking questions isn't enough. You need to listen to the answers, signal when something's wrong, and guide toward correction. That's where most forms fail.

A field turns red with no explanation. An "Error" message appears without saying where or why. The form clears itself after a failed submission. The user starts over from scratch without knowing what went wrong.

This article covers the second half of the conversation: validate, signal, correct.

Errors that help

An error message has one mission: enable the user to correct. If it doesn't say what to fix and how, it's useless.

"Error" says nothing. "Invalid field" says almost nothing. "This field expects an email address in the format name@domain.com" says everything.

The mechanism relies on two attributes:

<label for="email">Email address</label>
<input
  id="email"
  type="email"
  required
  aria-describedby="email-error"
>
<p id="email-error" class="error-message"></p>

// Toggle the state and fill the message at validation time
function setFieldError(field, message) {
  const errorNode = document.getElementById(`${field.id}-error`);
  field.setAttribute('aria-invalid', 'true');
  errorNode.textContent = message;
}
 
function clearFieldError(field) {
  const errorNode = document.getElementById(`${field.id}-error`);
  field.removeAttribute('aria-invalid');
  errorNode.textContent = '';
}

input:user-invalid {
  border-color: var(--color-error);
}
 
.error-message {
  color: var(--color-error);
  font-size: var(--font-size-sm);
}
 
.error-message:not(:empty)::before {
  content: "⚠";
  margin-inline-end: var(--space-1);
}

Two traps to avoid. First, aria-invalid="true" must not be hard-coded in the HTML: copied as-is, the field would be flagged invalid on page load. It's set dynamically, by JavaScript, at validation time. Second, no aria-live="polite" on the message itself: the message is already the target of aria-describedby, and the error summary carries role="alert". Combining both on the same element risks a double announcement. The announcement comes from the summary (immediate) and from the description (read when the field receives focus). If you insist on an immediate announcement during blur validation, test it with a screen reader before claiming it works.

aria-invalid="true" tells assistive technology the field contains an error. aria-describedby links the field to the message explaining the error. The screen reader announces: "Email address, invalid, This field expects an email address in the format name@domain.com."

The visual signal follows the same principle as colors that must never be alone. Border, text, and icon.

Some rules for error messages:

• Say what's wrong. "Enter your 10-digit phone number", not "This field is required"
• Say how to fix it. "Expected format: 555-123-4567", not "Invalid format"
• Stay near the field. The message must be visually adjacent to the field in error
• Don't disappear too quickly. The message stays visible until the error is corrected

These field-level messages are essential, but they're not enough alone for long forms. The next section covers the error summary — the big picture after submission.

Custom components

Native HTML offers <select>, <input type="date">, <input type="range">, <details>, <datalist>. They're accessible by default: keyboard navigable, correctly announced by screen readers, compatible with autocomplete and native validation.

And yet, most projects replace them with custom components. A <div> that looks like a <select>. A JavaScript calendar replacing <input type="date">. A homemade combobox reinventing <datalist>.

Why? Because native components are hard to style. <input type="date"> is the most telling example: its popup is a native OS widget, not a web element. In 2026, you still can't change its colors, layout, or typography. Its rendering varies between Chrome, Firefox, and Safari. WebKit pseudo-elements don't work everywhere. That's a valid reason to replace it. But it comes at a cost.

A custom calendar must reproduce everything the native one does for free:

• Keyboard navigation (Tab to enter, arrows to move between days, Enter to select, Escape to close)
• Screen reader announcement (role, current date, displayed month, selected day)
• Real-time updates (aria-selected, aria-current="date", aria-label on each day)
• Focus management (confinement in the open calendar, return to field on close)

Here's the minimal structure for an accessible calendar, and it's already substantial:

<label for="departure">Departure date</label>
<input
  id="departure"
  type="text"
  autocomplete="off"
  placeholder="dd/mm/yyyy"
>
<button
  aria-label="Choose departure date"
  aria-haspopup="dialog"
  aria-expanded="false"
>📅</button>
 
<dialog aria-label="Choose a date">
  <header>
    <button>Previous month</button>
    <h2 aria-live="polite">April 2026</h2>
    <button>Next month</button>
  </header>
  <table role="grid" aria-label="April 2026">
    <thead>
      <tr>
        <th scope="col" aria-label="Monday" title="Monday">M</th>
        <th scope="col" aria-label="Tuesday" title="Tuesday">T</th>
        <th scope="col" aria-label="Wednesday" title="Wednesday">W</th>
        <th scope="col" aria-label="Thursday" title="Thursday">T</th>
        <th scope="col" aria-label="Friday" title="Friday">F</th>
        <th scope="col" aria-label="Saturday" title="Saturday">S</th>
        <th scope="col" aria-label="Sunday" title="Sunday">S</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td tabindex="-1" aria-label="1 April 2026">1</td>
        <td tabindex="-1" aria-label="2 April 2026">2</td>
        <!-- ... -->
        <td tabindex="0" aria-selected="true" aria-current="date" aria-label="22 April 2026">22</td>
        <!-- ... -->
      </tr>
    </tbody>
  </table>
</dialog>

And the JavaScript is still missing: keyboard navigation between days (arrows), between months (Page Up/Down), between years (Shift + Page Up/Down), return to field on selection, Escape to close, dynamic aria-label updates. Each behavior must be manually implemented. The native <input type="date"> does it in zero lines of code.

Before building a custom component, ask yourself three questions:

1. Does the native element suffice? An <input type="date"> with a good label + min/max + validation combination often covers the need. A <datalist> combined with an <input> gives a native combobox.
2. Can the design adapt? Sometimes, accepting the native element's limitations costs less than maintaining an accessible custom component.
3. If I have no choice, am I following the ARIA pattern? The ARIA Authoring Practices Guide documents each pattern (combobox, dialog, grid, tabs, accordion) with the expected keyboard interactions, roles, and states. Not following them is reinventing the wheel as a square.

ARIA is covered in two articles: the poison and the scalpel. The golden rule: if a native HTML element does the job, use it.

Sources

• W3C WAI — Form notifications
• W3C WAI — ARIA Authoring Practices: Date Picker
• ARIA Authoring Practices Guide
• MDN — :user-invalid
• MDN — aria-live
• MDN — aria-invalid
• MDN — aria-describedby
• MDN — dialog
• MDN — input type="date"