Interacting with some UI components may position the cursor in an unexpected location (removing a Tag.)

[jeffkraemer2]

When using the keyboard to remove a Tag as shown in the screenshot below:

on activation the button is removed from the DOM, leaving the keyboard cursor in an unexpected position. Chrome based browsers do a good job in guessing where it might go next, but others shift focus back to the top of the page.

Ideally the system should shift focus and place the keyboard cursor somewhere logical in order for the user to continue from that point.

[jeffkraemer2]

I think this should be owned by Polaris, because it's about the behviour of the tag component itself rather than an instance in the Admin. @dominikwilkowski, do you agree?

[dominikwilkowski]

@jeffkraemer2 this can't be built into the component itself as it won't have the context of what is around it. It's an implementation detail for the consumer of Polaris. Having said that we should make it much easier on Polaris side to not fall into this trap. I will give my team a heads up about this.

[kyledurand]

This is sort of something we've thought about before, like having a global context manager to keep track of focus position but like Dom said it falls out of the realm of Polaris and its components.

In theory consumers could already track this and hook into the onRemove callback then shift focus to the next or previously focused elements but they way the system is right now (purely agnostic of its consumers) we wouldn't be able to do this from purely the Polaris side.

We've done some focus management with Modal, where when you dismiss one it will return focus to the element that activate the modal, but that's an optional prop and consumers don't necessarily use it all the time. I'm sure there are other dismissible elements that would need this treatment as well, like dismissible banners.

It's a hard problem, and the easiest thing to do would be to move focus when the onRemove callback is triggered which should probably be handled by the tag card component in web. Not saying this doesn't fall on the Polaris team, just providing some context.

[sophschneider]

There are utilities in web here that consumers can call onRemove to move the focus to the next element, previous element, etc. which has been the typical best practice thus far for web. As it stands, its on consumers to implement and test their keyboard flows just like they do for clicks, since they have the full context on what the flow should be.

[github-actions[bot]]

Hi! We noticed there hasn’t been activity on this issue in a while. After 30 days, it will close automatically.

If it’s still relevant, or you have updates, comment and let us know. And don’t worry, you can always re-open later if needed.