You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split from #14378, which covers format: html only.
WCAG: 2.1.1 Keyboard (A), 2.1.3 Keyboard, No Exception (AAA)
axe rule: scrollable-region-focusable — reports the .scrollable slide and the reveal-menu .active-menu-panel, but not the code blocks. The code-block half of this issue is invisible to axe; see below.
Targets: .reveal pre code, .scrollable slides, reveal-menu .active-menu-panel
theme.scss gives .reveal pre codeoverflow: auto; max-height: 400px. The scroll container is therefore the code element, not the div.sourceCode wrapper as in HTML output. At 390x844 the wide block hides 192px to the right and the tall block hides 215px below; div.sourceCode and pre both measure 0 overflow.
A keyboard user cannot reach that hidden content. Tabbing into the wide block lands on the line-number link for line 1 and leaves scrollLeft at 0, so all 192px stay clipped.
Why axe stays silent. revealjs turns on code line numbers by default. Pandoc emits a real fragment link per numbered line (<a href="#cbN-n">), which is focusable by design — it is how a reader links to a line. Without line numbers Pandoc instead emits a decorative anchor carrying aria-hidden="true" tabindex="-1". scrollable-region-focusable passes any scrollable region containing focusable content, so a numbered block satisfies the rule.
The rule is satisfied, but the region still cannot be scrolled. Line anchors sit at the start of each line, so focusing one never moves the region horizontally: measured scrollLeft stays 0 with 192px still clipped. Vertical overflow fares better, since tabbing down the anchors does scroll the block, at a cost of one tab stop per line (25 for the block above).
The focusable anchors are deliberate and are not the bug here. #14655 (fa5f81c) added aria-label to them and explicitly rejected aria-hidden, "since these anchors are real, focusable fragment links, and aria-hidden on a focusable element is itself an accessibility violation." Any fix should keep them focusable.
Scrollable slides and the menu panel
A .scrollable slide is reported by axe (#scrollable-slide), as are body and #slide-N on several quarto-web decks, and the reveal-menu .active-menu-panel at both 390x844 and 1440x900.
Constraints
revealjs binds the arrow keys to slide navigation, so making a region focusable is not sufficient on its own — the keys that scroll it must not fight slide navigation.
Related: #14710 (same rule, the axe report UI on revealjs and dashboard), #14249 (same vendored slide-menu component, different rule), #13574 (prior a11y work on revealjs code line numbers).
Split from #14378, which covers
format: htmlonly.WCAG: 2.1.1 Keyboard (A), 2.1.3 Keyboard, No Exception (AAA)
axe rule:
scrollable-region-focusable— reports the.scrollableslide and the reveal-menu.active-menu-panel, but not the code blocks. The code-block half of this issue is invisible to axe; see below.Targets:
.reveal pre code,.scrollableslides, reveal-menu.active-menu-panelRepro:
Code blocks
theme.scssgives.reveal pre codeoverflow: auto; max-height: 400px. The scroll container is therefore thecodeelement, not thediv.sourceCodewrapper as in HTML output. At 390x844 the wide block hides 192px to the right and the tall block hides 215px below;div.sourceCodeandpreboth measure 0 overflow.A keyboard user cannot reach that hidden content. Tabbing into the wide block lands on the line-number link for line 1 and leaves
scrollLeftat 0, so all 192px stay clipped.Why axe stays silent. revealjs turns on code line numbers by default. Pandoc emits a real fragment link per numbered line (
<a href="#cbN-n">), which is focusable by design — it is how a reader links to a line. Without line numbers Pandoc instead emits a decorative anchor carryingaria-hidden="true" tabindex="-1".scrollable-region-focusablepasses any scrollable region containing focusable content, so a numbered block satisfies the rule.The rule is satisfied, but the region still cannot be scrolled. Line anchors sit at the start of each line, so focusing one never moves the region horizontally: measured
scrollLeftstays 0 with 192px still clipped. Vertical overflow fares better, since tabbing down the anchors does scroll the block, at a cost of one tab stop per line (25 for the block above).The focusable anchors are deliberate and are not the bug here. #14655 (fa5f81c) added
aria-labelto them and explicitly rejectedaria-hidden, "since these anchors are real, focusable fragment links, and aria-hidden on a focusable element is itself an accessibility violation." Any fix should keep them focusable.Scrollable slides and the menu panel
A
.scrollableslide is reported by axe (#scrollable-slide), as arebodyand#slide-Non several quarto-web decks, and the reveal-menu.active-menu-panelat both 390x844 and 1440x900.Constraints
tabindex="0"to scrollers on.pastand.futureslides would add more phantom tab stops, while theinertfix proposed there would neutralize them. These two want fixing together, or in that order.Related: #14710 (same rule, the axe report UI on revealjs and dashboard), #14249 (same vendored slide-menu component, different rule), #13574 (prior a11y work on revealjs code line numbers).
Part of #8706.