A more proper way to query form inline errors

References:

• https://hiddedevries.nl/en/blog/2017-04-04-how-to-make-inline-error-messages-accessible
• https://w3c.github.io/aria/#status
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_status_role

Describe the feature you'd like:

Until today, I've always used getByTestId to find a form inline error:

<form aria-label="form">
  <fieldset>
    <label for="email">Email</label>
    <input type="email" id="email" />
    <output data-testid="email-error" for="email">Email is required.</output>
  </fieldset>

  <fieldset>
    <label for="password">Password</label>
    <input type="password" id="password" />
    <output data-testid="password-error" for="password">Password is required.</output>
  </fieldset>

  <button type="submit">Submit</button>
</form>

But I'm always wondering if there is a more semantic / accessible way to both write the markup and find it in my tests.

In the html example I'm using the output tag with the for attribute (I'm still not very sure that its the proper use of this tag, lets discuss that 🤔), so maybe we could support a query like getByRole('status', {name: 'something'}) or another more getByLabelText style.

Suggested implementation:

I think that first we need to discuss the proper way to write an accessible inline form error and if possible to link it with its own input(s) (like a label).

Describe alternatives you've considered:

I've red in an article that a <div role="alert"> can be used, but is missing way to link it to the input(s), and AFAIK role="alert" is not the same as role="status" (the role from output tag).

Teachability, Documentation, Adoption, Migration Strategy:

Same as "Suggested Implementation"

Start by reviewing the linked ARIA and accessibility references, then inspect the existing getByTestId, getByRole, and getByLabelText query behavior. The issue needs a decided accessible inline-error pattern and concrete query semantics before completion can be defined; no files or tests are identified.