-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[a11y]: Dismissible tabs component issues #14373
Comments
There are actually two different issues here, neither of which are addressed by the now resolved issue on labelling you reference (which I agree I captured somewhere, just not in this issue). The second issue (focus lost when ALL tabs are dismissed), you've acknowledged and termed not a carbon issue. Since it's hopefully a pretty rare occurrence, I'm fine with that. However, the first issue is the lack of focus placement after any tab is deleted, and it is going to occur wherever a dismissable tab is dismissed. The problem is the focus has been left in limbo, because the item that had focus was just deleted. Fortunately, the keyboard position is preserved in the DOM order, so the user can press tab once to refocus on the next item in the focus order. If not for that, this would be a more serious issue. If it's not acted on, I don't think this is a game stopper, but I wanted to make sure it was clear what I was flagging. We discussed a similar issue with people deleting a row that currently has focus in a table. I think @tay1orjones was in on that discussion. We came up with the logical way focus should be set after a deletion to make it a consistent experience. I don't see why the same pattern can't be adopted for dismissible tabs. I think what I describe in the initial issue (put focus on next item) makes sense and would make this consistent with the row deletion. I also think what I describe for the use case where the only tab is dismissed (put focus on prior tabstop) is consistent with what we arrived at for a table whose only row was just deleted. Not going to lose much sleep if you leave this closed, but wanted to ensure you were aware of what seemed to be unaddressed when closing it. |
Package
@carbon/react
Browser
Chrome
Operating System
MacOS
Package version
https://react.carbondesignsystem.com/?path=/story/components-tabs--dismissable
React version
No response
Automated testing tool and ruleset
n/a
Assistive technology
No response
Description
One minor accessibility issues with dismissible tabs.
Dismissible tabs have a focus handling issue. When a tab is dismissed with the Delete key, focus seems to go nowhere. There is a challenge here, in that the item that had focus has been removed. Where a tab other than the first tab item is deleted, focus should return to the 'prior' tab to the left. When the first tab is deleted, focus should move to the next one. If there is only one tab remaining, assuming that it can still be deleted, the focus would logically move to the prior focus point on the page. However, I question whether a user should be able to delete the only tab item remaining in the tablist. I feel like it should become undismissible until another tab item is added
WCAG 2.1 Violation
Name, Role, Value
Reproduction/example
https://react.carbondesignsystem.com/?path=/story/components-tabs--dismissable
Steps to reproduce
Focus
Code of Conduct
The text was updated successfully, but these errors were encountered: