Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Back-to-top button is not reachable by keyboard

Open Beginner friendly
  • Is something wrong?
#15,187 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
html, javascript
Domain
accessibility, frontend

Research direction

Start with the cited markup in src/project/types/website/website-navigation.ts#L631-L642 and the visibility behavior in src/resources/projects/website/navigation/quarto-nav.js#L51-L82. Render a website with back-to-top-navigation enabled and use keyboard navigation to check that the button can be focused and activated with Enter. Done means keyboard users can reach and activate it, with focus returning to the top as described.

Written by the indexing model from the issue text.

Description

accessibility bug html websites

I have:

  • searched the issue tracker for similar issues
  • installed the latest version of Quarto CLI
  • formatted my issue following the Bug Reports guide

Bug description

When back-to-top-navigation: true is set, keyboard users cannot reach or activate the "Back to top" button. This fails WCAG 2.1.1 Keyboard (Level A).

Quarto generates this markup (website-navigation.ts#L631-L642):

<a onclick="window.scrollTo(0, 0); return false;" role="button" id="quarto-back-to-top">
  <i class="bi bi-arrow-up"></i> Back to top</a>

The <a> element has no href and no tabindex, so it cannot take focus. role="button" does not make an element focusable.

Screen reader users are not blocked. VoiceOver reads the button, and VO+Space activates it, because VoiceOver sends a click. Keyboard users without a screen reader cannot reach it.

The button looks designed for mouse and touch users. The script shows it when the page scrolls up and hides it when the page scrolls down (quarto-nav.js#L51-L82). Keyboard users have other ways to go to the top, for example the Home key.

But 2.1.1 has no exception for this case. If a function is available with a mouse, it must also be available with a keyboard.

This was first reported in a comment on discussion #12644, tested with Chrome and NVDA.

Investigated with AI assistance, grounded in a local clone of quarto-cli.

Steps to reproduce

_quarto.yml:

project:
  type: website
website:
  back-to-top-navigation: true

index.qmd:

---
title: Long page
---

{{< lipsum 20 >}}

[A link](https://example.com)
  1. Render the site and open _site/index.html.
  2. Press Tab through the page to the end.
  3. Press End to show the button. Then press Shift+Tab.

Actual behavior

  • Tab never puts focus on the button. Focus goes from the last link back to the browser.
  • After End, the button shows, but Shift+Tab goes to the last link in the content.
  • document.getElementById("quarto-back-to-top").focus() has no effect.

Tested in Chromium with Playwright and real key presses.

Expected behavior

A keyboard user can Tab to the button, activate it with Enter, and the next Tab starts at the top of the page.

Your environment

  • IDE: none (rendered with the CLI)
  • OS: macOS 27.0.1 (build 26A434)

Quarto check output

Quarto 1.11.6
[✓] Checking environment information...
      Quarto cache location: /Users/charlottewickham/Library/Caches/quarto
      Project: none found (single-file mode)
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.10.0: OK
      Dart Sass version 1.101.0: OK
      Deno version 2.7.14: OK
      Typst version 0.15.1: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.11.6
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: v2026.04
      Chrome Headless Shell: 150.0.7871.115
      VeraPDF: 1.28.2

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/charlottewickham/Library/TinyTeX/bin/universal-darwin
      Version: 2026

[✓] Checking Chrome Headless....................OK
      Using: Chrome Headless Shell installed by Quarto
      Path: /Users/charlottewickham/Library/Application Support/quarto/chrome-headless-shell/chrome-headless-shell-mac-arm64/chrome-headless-shell
      Version: 150.0.7871.115

[✓] Checking basic markdown render....OK

[✓] Checking R installation...........OK
      Version: 4.6.0
      Path: /Library/Frameworks/R.framework/Versions/4.6/Resources
      LibPaths:
        - /Users/charlottewickham/Library/R/arm64/4.6/library
        - /Library/Frameworks/R.framework/Versions/4.6/Resources/library
      knitr: 1.51
      rmarkdown: 2.31

[✓] Checking Knitr engine render......OK

[✓] Checking Python 3 installation....OK
      Version: 3.12.2
      Path: /Users/charlottewickham/.pyenv/versions/3.12.2/bin/python3
      Jupyter: 5.9.1
      Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking Julia installation...
Dominant language
JavaScript
Stars
6.1k
Forks
471
Avg merge
17h 35m
Merged PRs (30d)
107

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from quarto-dev/quarto-cli

All issues in quarto-dev/quarto-cli

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.