quarto-dev / quarto-dev/quarto-cli
Keyboard tabbing order of tabset tabs and focusable controls within tabset content
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 6k
- Forks
- 458
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 41
Description
I'm seeing some inconsistency with the keyboard tabbing order when I use tabsets.
In this example, in which I've styled the tabs to appear at the bottom of the page (deployed version available here), the tabs have tabindex="0" and so are tabbable - but tabbing to put focus on them activates them, so it's impossible to then tab onto focusable elements within the tabset content (eg. checkboxes or dropdowns) unless you click on one of them first.
In the following example, the tabs aren't receiving any tabindex attribute at all and so aren't tabbable:
---
title: "Test tabs"
author: "jimjamslam"
---
Let's try some tabs!
::: {.panel-tabset}
## Tab A
This is just some explanatory text. No biggie...
## Tab B
Let's add some focusable controls here!
```{ojs}
viewof catSelect = Inputs.select(
["Apple", "Banana", "Orange", "Kiwi"],
{ label: "Choose a fruit"});
viewof numSelect = Inputs.range([1, 20], { label: "And a number" });
```
## Tab C
Some more text here! Could be lots of stuff.
```{ojs}
viewof check = Inputs.checkbox(
["Don't forget to check this!"],
{ label: "Options" })
```
## Tab D
Nah, this is all boring.
:::
Ideally, I expect that tabset tabs would be tabbable, but that tabbing onto a different tab would focus it without activating it so that I could continue on to any controls visible (unless I explicitly activated it as I might a hyperlink).
I'm not quite sure why the tabs in my first example have tabindex and the ones in my second don't, unless there's been a change in behaviour that I missed (although I believe I rendered them both with them same versions of everything). (Maybe the styling I used on the tabs in the first, adding display: flex and flex-direction: column-reverse to .panel-tabset to put the tabs below the content, did something weird?)
I think I've said "tab" enough for the rest of the year now 😂
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the two tabset examples linked in the issue and inspect their generated tab markup, tabindex values, and focus behavior. Compare normal tabsets with the version styled using display:flex and flex-direction:column-reverse; done means keyboard navigation reaches the tabs and controls in a consistent, accessible order without unexpectedly activating a tab.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- accessibility, frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100