Inputs: Align ARIA invalid state with computed validation errors#12972
Merged
danielchalmers merged 2 commits intoMudBlazor:devfrom Apr 7, 2026
Merged
Inputs: Align ARIA invalid state with computed validation errors#12972danielchalmers merged 2 commits intoMudBlazor:devfrom
danielchalmers merged 2 commits intoMudBlazor:devfrom
Conversation
## Why MudBlazor already renders validation and conversion errors visually, but the accessibility state exposed on the actual focus target was narrower than the state shown to the user. In practice, that meant a control could be visibly invalid while still reporting itself as valid to assistive technology. The clearest case was conversion/parsing failures: the error text appeared, but the focused input could still expose `aria-invalid="false"` because the rendered ARIA state followed the raw `Error` parameter instead of the computed error state. That mismatch is more than a polish issue: - It gives screen reader users different feedback than sighted users. - It makes validation semantics inconsistent across wrapper components. - It weakens trust in the component model, because the outer control and the inner focus target can disagree about whether the field is invalid. ## Reasoning The accessibility contract should follow the same state model that drives the visible error UI. If MudBlazor considers a field invalid because of validation or conversion, the element that actually receives focus should expose that same invalid state. Otherwise the framework is effectively telling assistive technology that nothing is wrong while showing an error on screen. This is especially important in wrapper-based components such as text fields, numeric fields, selects, autocomplete, and pickers, where the user interacts with an inner input but the error state often originates higher in the component stack. If that state is not carried through consistently, the rendered ARIA semantics become unreliable. ## Scope This PR is intentionally limited to the highest-confidence part of the problem: making invalid-state semantics follow computed errors consistently. It does not try to solve every helper/error relationship in one pass. More advanced follow-up work like broader error-message linkage can build on this baseline, but the baseline itself needs to be correct first.
mudbot
bot
changed the title
mudbot
bot
added
accessibility
danielchalmers
changed the title
ScarletKuro
approved these changes
Apr 7, 2026
This was referenced Apr 8, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some inputs could render an error while the focused input still exposed itself as valid because the ARIA invalid state followed the raw
Errorparameter, not the full computed error state. As a result, conversion and validation failures could be visible on screen but not communicated correctly to assistive technology.If it shows a field as invalid, the real input element should also report it as invalid. Anything else creates inconsistent behavior between visual validation and screen reader output.
Checklist: