Add showValidationMessage() method for validation without focus management

[Hideki-Kobayashi]

What problem are you trying to solve?

Add showValidationMessage() method for validation without focus management

Problem

The current reportValidity() method automatically refocuses the validated element when validation fails, creating poor user experience and accessibility issues.

Issues with current behavior:

1. Focus trapping: Users cannot navigate away from invalid fields
2. Poor UX: Interrupts natural form navigation flow
3. Accessibility problems: Confuses screen reader users

Real-world scenario:

// User types invalid email, then presses Tab
emailInput.addEventListener('blur', () => {
  if (!emailInput.checkValidity()) {
    emailInput.reportValidity(); // Shows error BUT forces focus back
    // User is now trapped - cannot move to next field
  }
});

Proposed Solution

Add a new method showValidationMessage() that displays validation errors without focus management:

// New API - message only, no focus management
element.showValidationMessage();

// Existing API - message + focus (backward compatibility)
element.reportValidity();

Use Case

Real-time validation without focus trap:

field.addEventListener('blur', () => {
  if (!field.checkValidity()) {
    field.showValidationMessage(); // Show error, allow navigation
  }
});

This would significantly improve form validation UX while maintaining backward compatibility.

What solutions exist today?

No response

How would you solve it?

No response

Anything else?

No response

[annevk]

How would this work accessibility-wise? cc @keithamus

[keithamus]

It seems reasonable to me to add an opt-in method name (or option in an options bag) to prevent focusing, with the understanding that the web developer will need to handle focus management themselves. I can imagine a variety of scenarios where a developer can come up with a more accessible solution that the current prescriptive methods (but I can also imagine many ways in which developers can make this less accessible so we need to be a little careful here).

I think it's worth fielding the opinions of accessibility practitioners here, though. Specifically I imagine @smhigley has some experience in this area, and would be able to offer some excellent insight.

[annevk]

cc @whatwg/a11y