Tab Content Focus Weirdness #1145
-
|
Howdy! Tab content is focusable which seems like a useful thing for a11y but it generates some weird artifacts when you interact with the tab content even within the docs.
It also doesn't look great when we include it in some of our designs for the new Email Insights product.
I'm just wondering if the focus border could be lessened or we can add some whitespace/move where the border begins. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
+1 I'm wondering if the focus area appearing around tab body content is even expected? My understanding is that focus is for determining where keyboard events go (but that may be an incorrect understanding), so it makes sense on the actual tab where an event can be triggered, but the wrapping body div doesn't have any events to trigger. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @GiantRobots and @seanmateer ! Great question. This article helped me better understand why keyboard handling and focus states for Tabs are slightly different than more straightforward content: https://css-tricks.com/tabs-its-complicated/. There's a link to a more detailed article in there too, which gets into specifics around what the experience is like for users who rely more on screen readers than the visual Tab controls (see the "A problem reading panels" section). Because of the way Tabs are built, the Tab content panel needs its own focusable state. Otherwise, screen readers will skip over the content if there's no focusable element inside it. Additionally, for people who rely on both on the visible focus state and keyboard interactions, keeping a visible focus cue can help make navigating by keyboard still be predictable (so that you don't just see a focus state disappear, for example, when you're tabbing to the next thing). That being said, you might've noticed that the focus state on the Tab content panel isn't the same as our typical focus state. That's something we'll have to improve on—the component's still in alpha, so there's definitely room for another design pass. With our normal focus state, it'll be slightly softer, and we'll make sure to do some exploration with different content types so it works well with bordered content like you have in the screenshot. If you have more suggestions, please let us know! Here's the ticket for Tabs design and docs improvements in our backlog if you want to follow along: https://issues.corp.twilio.com/browse/DSYS-2010 |
Beta Was this translation helpful? Give feedback.
-
|
Previous discussion: #995 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @GiantRobots. We just released an update to Tabs, and adjusted the focus state to be inline with other Paste component focus states. We also suggest adding a small amount of padding to the TabPanel content using Box if you want a little breathing room between the focus outline and the content. Something like |
Beta Was this translation helpful? Give feedback.
Hey @GiantRobots and @seanmateer ! Great question. This article helped me better understand why keyboard handling and focus states for Tabs are slightly different than more straightforward content: https://css-tricks.com/tabs-its-complicated/. There's a link to a more detailed article in there too, which gets into specifics around what the experience is like for users who rely more on screen readers than the visual Tab controls (see the "A problem reading panels" section).
Because of the way Tabs are built, the Tab content panel needs its own focusable state. Otherwise, screen readers will skip over the content if there's no focusable element inside it. Additionally, for people who rely o…