Visual Asterisks Don't Work: Why Required Field Design Fails Screen Readers

I've been auditing forms for over a decade, and there's one accessibility issue that shows up so consistently it might as well be a law of web development: the visual-only asterisk for required fields. It's everywhere, it looks clean, and it completely fails disabled users.

The WCAG repo example (opens in new window) demonstrates this perfectly. Three form fields—username, email, and phone—all marked with red asterisks that scream "required" to sighted users. But fire up a screen reader, and those asterisks vanish into the digital void.

The Technical Breakdown

This isn't just a minor usability hiccup. It's a clear violation of WCAG 3.3.2 (Labels or Instructions) (opens in new window), which requires that instructions for user input be programmatically available to assistive technology.

Here's what's happening under the hood:

<!-- What developers typically write -->
<label for="username">Username *</label>
<input type="text" id="username" name="username">

<!-- What screen readers actually get -->
<label for="username">Username</label>
<input type="text" id="username" name="username">

That asterisk? It's usually styled with CSS or inserted as plain text that screen readers either skip entirely or announce as "asterisk"—which tells users exactly nothing about whether the field is required.

Real User Impact

When I'm testing with screen reader users, this pattern creates a specific type of frustration. Users tab through forms, fill out what seems optional, hit submit, and get bounced back with validation errors they couldn't have anticipated. It's not just annoying—it breaks trust.

One developer I worked with in Bellevue put it well: "We spent months perfecting the visual hierarchy, but we accidentally made our form completely unusable for anyone who can't see it."

The operational impact is real too. Customer service teams field calls from confused users who "can't figure out why the form keeps rejecting their information." That's not a user problem—that's a development problem with a clear technical solution.

The Fix: Multiple Approaches

The good news? This is completely solvable, and you don't have to sacrifice your visual design. Here are three approaches that work:

Option 1: Semantic HTML with ARIA

<label for="username">Username *</label>
<input type="text" id="username" name="username" aria-required="true">

The aria-required="true" attribute tells screen readers this field is required. Simple, semantic, and works everywhere.

Option 2: Descriptive Text with aria-describedby

<label for="username">Username</label>
<input type="text" id="username" name="username" 
       aria-required="true" aria-describedby="username-req">
<span id="username-req" class="sr-only">(required)</span>

This approach gives you more control over the announcement. Screen readers will say "Username, required, edit text" instead of just "Username, edit text."

Option 3: Enhanced Instructions

<fieldset>
  <legend>Contact Information (fields marked with * are required)</legend>
  <label for="username">Username *</label>
  <input type="text" id="username" name="username" aria-required="true">
  <!-- more fields -->
</fieldset>

This provides context upfront and works especially well for longer forms.

The HAL Approach: Automated Detection

The example mentions HAL (presumably an accessibility testing tool) that detects visual asterisks and automatically injects the proper ARIA attributes. This kind of automated remediation is interesting from a organizational capacity perspective—it can provide a bridge while teams build better practices.

But here's the thing: automated fixes are band-aids. They work, but they're treating symptoms rather than causes. As I discussed in The False Promise of Automated Accessibility Testing, these tools can catch obvious issues but they can't build accessibility into your design process.

Beyond Required Fields: Form Design Patterns

This asterisk issue is part of a larger pattern where visual design conventions don't translate to assistive technology. Other common form accessibility issues I see regularly:

• Error messages that appear visually but aren't announced to screen readers
• Placeholder text used instead of proper labels
• Color-only indicators for validation states
• Multi-step forms without proper progress indicators

Each of these follows the same pattern: works fine visually, breaks completely for assistive technology users.

Implementation Strategy

From an operational standpoint, fixing required field indicators is actually a great starting point for teams building accessibility capacity. It's:

• Low complexity: Single attribute addition
• High impact: Affects every form on your site
• Easy to test: Screen reader testing shows immediate results
• Measurable: You can audit compliance across your entire form library

I typically recommend this as part of what I call the "accessibility chop list"—quick wins that solve real problems while teams build toward more systematic accessibility implementation.

The Bigger Picture

Required field indicators might seem like a small detail, but they represent something larger: the gap between visual design and semantic meaning. When we design primarily for visual users, we create digital environments that exclude people who interact with content differently.

The Pacific ADA Center (opens in new window) frequently emphasizes that accessibility isn't about adding features for disabled users—it's about ensuring that the features we build work for everyone. Required field indicators are a perfect example. The semantic markup that makes forms accessible to screen readers also enables better automated testing, clearer form validation, and more robust error handling.

Moving Forward

If you're maintaining forms with visual-only required indicators, here's your action plan:

1. Audit existing forms for missing aria-required attributes
2. Update your form component library to include proper ARIA by default
3. Test with actual screen readers—NVDA is free and will show you exactly what users experience
4. Document the pattern so new team members implement it correctly

This isn't just about compliance—though it does address WCAG 3.3.2 requirements (opens in new window). It's about building digital experiences that actually work for the people trying to use them.

The asterisk might be a small symbol, but fixing it properly signals something important: your team understands that accessibility isn't an afterthought—it's a fundamental part of building software that serves everyone.