[a11y]: Dismissible tabs component issues

[mbgower]

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.

• focus

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

1. Stay in same dismissible storybook version
2. With keyboard, tab to tablist and arrow between tab items
3. Press Delete to dismiss the tabitem. The item disappears, and so does the focus indicator. FIRST PROBLEM
4. Press Tab and a different tab takes focus.
5. Continue to Delete tabs until all are gone. No focus indicator. SECOND PROBLEM

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[guidari]

Hey @mbgower we made a separete issue to address the issue about the labeling 14507.

The issue about the user being able to close all the tabs is up to them with the prop handleCloseTabRequest, so it's not a carbon issue. But the focus after deleting a tab we should take a look.

[mbgower]

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.