fix(multiple-choice/ebsr): correct keyboard navigation between EBSR parts using native radiogroup semantics PIE-174#3017
Merged
Merged
Conversation
…p EBSR parts in separate radio groups regardless of partLabels setting PIE-174
…on the first radio in a group, use a unique random radio group name per instance so EBSR parts stay independent regardless of partLabels PIE-174
…rop fieldset tabIndex workaround PIE-174
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
1 participant
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.
https://illuminate.atlassian.net/browse/PIE-174
The radio
nameattribute was derived from the visible part label,so items with partLabels: false (e.g. when authors write their own
"Part A" / "Part B" into the prompt) collapsed both parts into one
big radio group: arrow keys crossed parts and Tab got trapped on the
selected radio. To work around that, each fieldset had tabIndex={0}
plus a handleGroupFocus handler that redirected focus via
firstInputRef / autoFocusRef — but after the MUI v7 migration the
autoFocusRef stopped reaching the underlying input (the wrappers
rebuilt slotProps from a never-passed inputRef prop), causing focus
to land on the empty fieldset and forcing the user to press Tab and
Shift+Tab twice to traverse parts.
partLabels now controls only the visible heading and no longer
affects keyboard or screen-reader grouping.