[Bug]: Standard `viewer.html` uses unnecessary tabindex on `#viewerContainer` element
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 53.9k
- Forks
- 10.7k
- Avg merge
- 18h 38m
- Merged PRs (30d)
- 130
Description
Attach (recommended) or Link to PDF file
In the standard viewer.html there seems to be an unnecessary tabindex on the #viewerContainer element:
https://github.com/mozilla/pdf.js/blob/384c6208b257e81fa7bcd4e59dc100e3c99d9528/web/viewer.html#L839
It is not clear to me why the element has tabindex on it. If I focus on it with my keyboard, there is no visual indicator that the element is focused.
Can it be removed?
Web browser and its version
Microsoft Edge Version 144.0.3719.115 (Official build) (arm64)
Operating system and its version
MacOS 26.2 (25C56)
PDF.js version
5.4.624
Is the bug present in the latest PDF.js version?
Yes
Is a browser extension
No
Steps to reproduce the problem
- Go to the demo: https://mozilla.github.io/pdf.js/web/viewer.html
- Use tab on the keyboard to cycle through elements. After the right-most element Tools, and before the first PDF page, focus is on the
#viewerContainerelement - See that nothing is visually indicated
- See that it appears unnecessary for there to be something to focus between the right-most element Tools. and the first PDF page
What is the expected behavior?
To me the expected behavior is that the #viewerContainer is not focusable. If it must be focusable, it should at least have a visual indication that it is focused.
What went wrong?
I used the keyboard to cycle through elements and saw that it focuses on #viewerContainer but I don't understand why it is in focus.
Link to a viewer
No response
Additional context
No response
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 at web/viewer.html around line 839 and reproduce the keyboard tab sequence in the demo viewer. Check why #viewerContainer is focusable and whether its focus state is represented visually. Done means the container no longer creates an unnecessary tab stop, or has a visible focus indication if focusability is required.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- accessibility, frontend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100