-
Notifications
You must be signed in to change notification settings - Fork 81
Fixed tab index order for tab press #755
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Fixed tab index order for tab press #755
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this! I left a comment with a small question.
@@ -28,10 +28,10 @@ const ActionItem = React.memo(({ | |||
style={{ cursor: 'pointer' }} | |||
aria-checked={value === selected} | |||
// eslint-disable-next-line jsx-a11y/no-noninteractive-tabindex | |||
tabIndex={value === selected ? '0' : '-1'} | |||
tabIndex={'0'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked the git blame and it looks like this line was added for #483
Can you confirm the issue that PR was fixing is still fixed with this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I’ve verified that the issue addressed in PR #483 is still resolved with the current change.
Thanks @brian-smith-tcril for pointing it out and for your thorough review!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should not have a tabindex on a Label, because it is a non-interactive role. This will throw a new error in automated testing.
Sandbox deployment successful 🚀 |
The required checks are failing. Other than that, the changes look good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes do feel like an improvement to me compared to what is currently on master
.
I did notice one thing though.
In my testing I wasn't able to select filters using the keyboard (pressing space or enter when a filter was focused did nothing). I think the inability to focus on non-selected filters on master
is hiding the inability to interact with the filters using the keyboard. Since the filters behave similarly to radio buttons, having nothing happen when pressing space or enter on a focused filter when it is selected is "correct" behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can give you more precise recommendations if you want to discuss.
@@ -28,10 +28,10 @@ const ActionItem = React.memo(({ | |||
style={{ cursor: 'pointer' }} | |||
aria-checked={value === selected} | |||
// eslint-disable-next-line jsx-a11y/no-noninteractive-tabindex | |||
tabIndex={value === selected ? '0' : '-1'} | |||
tabIndex={'0'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should not have a tabindex on a Label, because it is a non-interactive role. This will throw a new error in automated testing.
> | ||
<Icon src={Check} className={classNames('text-success mr-2', { invisible: value !== selected })} /> | ||
<Form.Radio id={id} className="sr-only sr-only-focusable" value={value} tabIndex="0"> | ||
<Form.Radio id={id} className="sr-only sr-only-focusable" value={value} tabIndex="-1"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should not have a tabindex on a input type="radio". The radiogroup will take focus as a single tab stop, and the selection within the group may be changed via arrow keys (assuming all items have the same name attribute ).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to wrap a label with an icon over a sr-only input which will take focus (which is not the technique used by the Paragon radio buttons and checkboxes, btw), you can use css::focuswithin on the wrapping Label. to change the visible focus styling.
@@ -42,10 +42,10 @@ export const ActionItem = React.memo(({ | |||
style={{ cursor: 'pointer' }} | |||
aria-checked={value === selected} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A label should never have an aria-checked attribute. The Form.Radio should have a regular checked value when appropriate.
The sandbox link does not show the associated UI. I'll give better feedback if you can show it live. |
https://app.pr-755-220000.sandboxes.opencraft.hosting/discussions/course-v1:demo+Course+1/posts and click |
@wittjeff The reason I approved this PR is not because it is perfect from an a11y stand point, but because it is a marked improvement over the existing behavior on `master. In the following screen recordings I am hitting tab repeatedly until I get to the end, and then hitting shift+tab. Using the arrow keys to select options does not work on either
|
I found it, thanks! |
It seems like this would be better implemented as a variation on the existing Paragon radio group, with a custom Icon used to indicated checked state. |
Description
On the Posts page, the keyboard focus was restricted to only the pre-selected option within the filter, and it was not moving to other non-selected options.
Steps to reproduce:
Related to overhangio/tutor-indigo#146
How Has This Been Tested?
I set up Tutor locally with the Indigo Plugin enabled (which is enabled by default). I followed the above steps to reproduce the issue, inspected the HTML on the frontend, and identified where the adjustment was needed. After applying the fix, the keyboard now correctly navigates through both selected and non-selected options using the tab key.
Screenshots/sandbox (optional):
Sandbox Link
Taiga Ticket (If someone have access)
Screenshots
Here is the screen where only selected options were keyboard accessible, but after making the fix it should be accessible for all the options.

Merge Checklist
Post-merge Checklist