ARIA2: Making Required Fields Programmatically Real

A user tabs into a form field. The label reads "Email address *" — the asterisk clearly signals this field is mandatory. But the screen reader announces only "Email address, edit text." The asterisk is invisible to it. The user submits the form, gets an error, and has no idea why. This is the gap WCAG Technique ARIA2 (opens in new window) exists to close.

The Technique

ARIA2 describes how to use the aria-required="true" property to programmatically communicate that a form field must be completed before submission. The technique's core premise: visual indicators of required fields — asterisks, color changes, the word "required" in parentheses — are presentation-layer signals. They work for sighted users. They don't automatically translate into information that assistive technology can convey.

aria-required="true" adds that programmatic layer. When set on an input, screen readers announce the field as required. The user knows before they skip it, not after they submit and receive a cryptic error.

This technique is listed as advisory for three success criteria: 1.3.1 Info and Relationships (opens in new window), 3.3.1 Error Identification (opens in new window), and 3.3.2 Labels or Instructions (opens in new window). Advisory means it's not the only path to meeting these criteria — but it's a well-established, reliable one.

One important note from the W3C document itself: aria-required="true" alone, without any visual indicator, doesn't serve most users. The technique assumes both layers are present — visual cue and programmatic attribute. Neither replaces the other.

Why This Matters

Form errors are one of the most common failure points for users with disabilities. Screen reader users navigate forms by moving through fields sequentially, often without a complete visual map of the form's structure. When required fields aren't programmatically marked, users discover the requirement only after submission fails — and error messages are frequently the next accessibility problem waiting to happen.

Keyboard-only users face a similar challenge. Without aria-required, the field's mandatory status exists only in the visual design. Switch users, voice control users, and people using refreshable Braille displays all depend on the same underlying semantic information that aria-required provides.

Users with cognitive disabilities benefit too. When a screen reader announces "First name, required, edit text," that's clearer and more direct than parsing a footnote at the top of the form that says "* denotes required fields." The requirement is attached to the field, not separated from it.

This is precisely the kind of failure that automated testing tools frequently miss — not because the tool can't detect a missing attribute, but because detecting whether a visual required indicator has a corresponding programmatic attribute requires understanding the relationship between CSS presentation and HTML semantics. Our research on testing methodology gaps shows this category of contextual mismatch is where automated tools consistently underperform.

How It Works

The W3C document provides two clear implementation patterns. The first uses an asterisk in the label:

<form>
  <p>Note: * denotes a required field</p>
  <div>
    <label for="usrname">Login name *:</label>
    <input aria-required="true" autocomplete="username" id="usrname" type="text">
  </div>
  <div>
    <label for="pwd">Password *:</label>
    <input aria-required="true" autocomplete="current-password" id="pwd" type="password">
  </div>
  <div>
    <input type="submit" value="Login">
  </div>
</form>

The second uses the word "required" as adjacent text:

<form>
  <div>
    <label for="fname">First name:</label>
    <span>(required)</span>
    <input aria-required="true" autocomplete="given-name" id="fname" type="text">
  </div>
  <div>
    <label for="lname">Last name:</label>
    <span>(required)</span>
    <input aria-required="true" autocomplete="family-name" id="lname" type="text">
  </div>
  <div>
    <label for="email">Email address:</label>
    <span>(required)</span>
    <input aria-required="true" autocomplete="email" id="email" type="text">
  </div>
</form>

Notice that in the second example, the (required) span is visually present for all fields — but aria-required="true" is only on the fields that are actually required. The middle name field (mname) has the visual label but not the attribute, which is a meaningful distinction. Visual and programmatic signals should match.

A note on HTML5: the native required attribute on <input> elements also communicates required status to assistive technology and triggers built-in browser validation. For standard HTML form controls, required is often the simpler choice. aria-required becomes essential for custom controls — date pickers, comboboxes, custom select menus — where native HTML validation doesn't apply.

Applying This

In code review: Check every form field that has a visual required indicator (asterisk, color, text) for a corresponding aria-required="true" or native required attribute. These should always appear as a pair. A field with one but not the other is a failure.

In design handoff: Required field indicators should be documented as a semantic requirement, not just a visual style. A design spec that says "asterisk = required" should also specify that aria-required="true" must be implemented. If your team uses a design system, the required field component should enforce this at the component level — not leave it to individual implementation.

In automated testing: Tools can detect the presence or absence of aria-required on inputs, but they can't reliably detect whether a visual asterisk exists without a corresponding attribute. This is a manual check. Add it to your QA checklist alongside label association and error message testing.

Quick audit: Open any form in your application. Tab through every field. For each one that has a visual required indicator, inspect the HTML. If you see * in the label but no aria-required="true" or required on the input, you have a gap to close.

Teams navigating multiple compliance frameworks — WCAG, Section 508, EN 301 549 — will find that this technique satisfies form requirements across all three. The standards fragmentation challenge is real, but aria-required is one of the places where the standards converge rather than conflict.

CORS Perspective

From a strategic alignment standpoint, ARIA2 is a low-cost, high-impact fix that sits squarely on the "chop list" — the category of quick wins that solve real user problems with minimal development effort. Adding aria-required="true" to existing form fields is an afternoon of work on most codebases, not a sprint. The risk calculus is straightforward: form inaccessibility is one of the most litigated categories of digital accessibility failures, and required field identification is a documented failure pattern in DOJ enforcement actions. The operational case for building this into component libraries and design systems — rather than auditing for it repeatedly — is equally clear. Fix it once at the component level; every form inherits the fix.