Semantics First, JavaScript Second

Building forms with JavaScript-only front-ends often means skipping the <form> tag entirely and collecting data through the FormData API. Austin Gil's opening post in his five-part series on "HTML Forms Right" makes the case that this misses the point: no <form> tag, no FormData, and no Enter-key submission either.

Developers building SPAs might argue that if the user sees the form, JavaScript is guaranteed to be running. But Gil pushes back on that assumption, noting that important forms may eventually need to support a no-JS world, particularly if server-side rendering (SSR) enters the picture. With Google's indexers reportedly taking up to a week or more to process client-side rendered pages, and SSR offering substantially faster load times, the benefits are becoming harder to ignore.

A follow-up piece from Oscar Braunert on inclusive inputs illustrates how close-and-yet-so-far form HTML can be, particularly when the connection between <label> and <input> is missing. Braunert then explores accessible patterns for marking up required fields and those with validation errors:

<div class="form-group">
  <label for="password">
    Password
    <span class="required" aria-hidden="true">*</span>
    <span class="sr-only">required</span>
  </label>
  <input 
    type="password"
    id="password"
    name="password"
    aria-describedby="desc_pw"
  >
  <p class="aside" id="desc_pw">Your password needs to have at least eight characters.</p>
</div>

Skip ARIA When You Can

Amber Wilson's approach to accessible HTML elements deliberately avoids ARIA altogether. Her reasoning is straightforward: it's worth seeing how far native HTML can take you before layering on roles and attributes.

Sarah Higley, however, dives into ARIA with a strong warning about the more powerful roles like menu, listbox, and treegrid. These patterns look appealing because they enable experiences vanilla HTML can't support, but they are brittle; small mistakes can lead users down a very bad path.

When ARIA is truly necessary, Higley demonstrates targeted fixes at the DOM level. One such technique involves role="presentation", which strips away an element's default role when that role gets in the way of the intended semantics.

A Sensible Order for Accessible Names

Adrian Roselli's guidance on labeling controls offers a clear hierarchy for assigning accessible names, favoring native approaches over ARIA-heavy ones:

  • Native HTML techniques first
  • aria-labelledby pointing at existing visible text
  • Visibly-hidden content still present in the page
  • aria-label last

The pattern across all these resources is consistent: start with semantic HTML, reach for ARIA only when native elements can't do the job, and when you do use ARIA, apply it with care and precision. As Higley puts it, talk to your kids about ARIA before it's too late.