Change "aria-invalid" attribute in response to auto-validation in data-input components

[sadtrick]

Currently, the data-input components (checkbox, radio, input, textarea, and select) implement some form of auto-validation to display an invalid message. However, as far as I understand, the "aria-invalid" attribute is not updated as part of this auto-validation process; it only changes via the "validation" prop ("invalid", "valid", or "no-validation").

For better accessibility and consistency, it would be helpful if the "aria-invalid" attribute automatically reflected the result of the component’s internal validation as well, not just the explicit "validation" prop.

Suggestion:
Please adjust the components so that "aria-invalid" is also set appropriately whenever an auto-validation error occurs, ensuring screen readers can provide accurate feedback to users.

[mfranzke]

@sadtrick thanks a lot for your feedback.

The validity of the form component is in general managed by the form element itself and can be retrieved via CSS (e.g. :user-valid) or JavaScript (e.g., the validity property or the checkValidity() method). There are additional ways to selectively override this internal state, e.g. via the HTML attribute aria-invalid="true" or the JavaScript method setCustomValidity(message). However, these are only meant for edge cases and for specific use cases that cannot be solved by existing attributes (like required, pattern, or determined by the type etc.) on these elements.

Adding an HTML attribute to reflect the built-in state seems unnecessary and complicated to me since the CSS and JavaScript-related properties and methods mentioned above already work correctly. Reflecting the internal state would require constant monitoring and calculation of the form elements' status, especially since the aria-invalid attribute would overwrite the existing state and isn't meant for reflecting it.

So regarding accessibility and consistency, it would actually be beneficial not to add it, as the built-in functionality already reports the correct validation state, and that attribute aria-invalid is only meant to overwrite it specifically. Programmatically defining the validation state via that attribute validation is just an overwrite that should only be used in edge cases.

If you do have another perspective or use case, let's further align on this.

[sadtrick]

@mfranzke thanks for the quick response!

I think my confusion comes from our mixed validation approach: on every change we render our own invalidMessage and only fall back to the native validationMessage. The current logic here:

core-web/packages/components/src/components/input/input.lite.tsx

Line 76 in 34210c8

handleValidation: () => {

In that setup, we’re effectively in a hybrid state: the invalidity may come from the native Constraint Validation API, but the displayed error text is author-defined.

To make this consistent for assistive technologies, would it make sense to:

• set aria-invalid="true" and link the visible error via aria-errormessage whenever our component displays a custom error message (even if the invalid flag originates from native constraints)
• refrain from setting aria-invalid when we rely entirely on native validation and its own message

Just to clarify, even if my messages make it obvious. I’m not an accessibility expert and I’m striving to improve. Thanks for the discussion! If you don’t see a need for further discussion, feel free to close this ticket.