How to Use aria-required Correctly: Complete Guide (2026)

Why Required-Field Signaling Matters

Required-field communication is one of the highest-leverage form accessibility issues. When a screen-reader user can't tell which fields are mandatory until after they submit and hear an error, the experience collapses:

• Form completion drops: users who fail submission, lose their place, and have to re-navigate often abandon entirely. Form-friction is one of the top conversion killers in e-commerce.
• Accessibility conformance: WCAG 2.2 SC 3.3.2 explicitly requires that labels or instructions identify required input. An asterisk alone — with no programmatic state — fails this criterion.
• Legal exposure: the European Accessibility Act (EAA) became enforceable on June 28, 2025, requiring WCAG 2.1 AA conformance for in-scope digital services. Form-input failures are among the most-cited issues in accessibility lawsuits in the US under ADA.
• SEO and AI search:Google's helpful-content evaluation considers accessibility friction as a ranking signal. AI search engines parse the accessibility tree to summarize forms and CTAs — required fields without proper roles are invisible to them.

How aria-required Actually Works

Setting aria-required="true" changes one thing: how a screen reader announces the field. NVDA might say "Email, edit, required" instead of just "Email, edit". That's the entire effect on the accessibility tree.

What it does not do, no matter what your designer hopes:

• It does not stop form submission with an empty value.
• It does not trigger a browser-native error tooltip.
• It does not add red border styling — that's your CSS's job.
• It does not work on roles outside the allowed list (the audit will fail).

<!-- BAD: aria-required on a button (audit failure — buttons can't be required) -->
<button aria-required="true">Submit</button>

<!-- BAD: visual asterisk only, no programmatic state -->
<label for="email">Email *</label>
<input id="email" type="email" />

<!-- BAD: aria-required without a visible cue — sighted users get no signal -->
<label for="phone">Phone</label>
<input id="phone" type="tel" aria-required="true" />

<!-- GOOD: native required + visible asterisk + screen-reader text -->
<label for="email-good">
  Email <span aria-hidden="true">*</span>
  <span class="visually-hidden">required</span>
</label>
<input id="email-good" type="email" required />

<!-- GOOD: aria-required on a custom combobox where native required doesn't apply -->
<label id="country-label">Country *</label>
<div
  role="combobox"
  aria-labelledby="country-label"
  aria-required="true"
  aria-expanded="false"
  aria-controls="country-listbox"
  tabindex="0"
></div>

<!-- GOOD: short-form pattern — label optional fields instead of required ones -->
<label for="first-name">First name</label>
<input id="first-name" type="text" required />

<label for="middle-name">Middle name (optional)</label>
<input id="middle-name" type="text" />

How to Check Your Forms for aria-required Issues

Required-field bugs hide in the accessibility tree, not the visual layout. They need tools that read what assistive technology actually sees.

• Greadme's deep scan — flags every form input where aria-required is misused (wrong role, missing visible cue, redundant alongside native required) and pairs each issue with an AI-generated fix or a one-click GitHub PR.
• Greadme's crawler scan — checks every indexable page on your site for required-field accessibility failures so you can spot template-level bugs (a checkout form repeated across 50 product pages).
• Greadme's AI visibility analyzer — shows how AI search engines see your forms and CTAs, so you can confirm required-state signals reach the accessibility tree AI bots parse.
• Chrome DevTools → Accessibility pane — inspect any form input and read the "required" computed property directly from the accessibility tree.
• NVDA, JAWS, VoiceOver, TalkBack — manual check: tab into each input and confirm the screen reader announces "required".
• Open-source axe-core — programmatic checks for invalid aria-required roles in CI.

8 Rules for Using aria-required Correctly

Common aria-required Mistakes and Fixes

aria-required vs. Other Required-Field Approaches

Three mechanisms can mark a field as required, and they are not interchangeable. Pick based on whether you need validation, screen-reader exposure, or both.

FAQ

Do I need aria-required if I use the native required attribute?

No. <input required> automatically sets aria-required="true" in the accessibility tree. Adding both is redundant and can cause maintenance drift if one is later removed. Use only native required on standard form inputs.

Which roles can aria-required be used on?

aria-required is meaningful on form-input roles: combobox, gridcell, listbox, radiogroup, spinbutton, textbox, tree, plus native form elements (<input>, <textarea>, <select>). On any other role — buttons, links, generic div — it is ignored and flagged by audits.

Does aria-required prevent form submission?

No. aria-required only changes how screen readers announce the field. It does not block submission, show errors, or trigger validation. Use the native required attribute or JavaScript validation if you need to actually prevent empty submissions.

Should I use aria-required="false"?

Almost never. The default state is implicit false, so omitting the attribute has the same effect. The "false" value is technically valid but adds noise to the accessibility tree and clutters your markup. Only set aria-required="true" on fields that genuinely require input.

Is a visual asterisk enough on its own?

No. An asterisk with no programmatic state fails WCAG 2.2 SC 3.3.2 (Labels or Instructions) and SC 4.1.2 (Name, Role, Value), because screen-reader users cannot determine the required state without submitting. Always pair the visible cue with native required or aria-required="true".

How do AI search engines like ChatGPT and Perplexity handle required-field forms?

AI search engines parse the accessibility tree when they extract form structure to summarize CTAs, lead-capture flows, or signup pages. A form where required state is encoded only in a visual asterisk produces an incomplete summary — the bot doesn't know which fields are mandatory. Pages with proper aria-required or native required markup are summarized accurately and cited more reliably.

What's better — marking required fields or marking optional ones?

For long forms with many required fields, marking only the optional fields with "(optional)" reduces visual noise and is recommended in the WAI-ARIA Authoring Practices. The required fields still get programmatic state via required, but the visual UI is calmer. For short forms with mostly optional fields, marking the required ones with an asterisk is clearer.