Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

negative tabindex not working as expected #2917

Closed
AHBruns opened this issue Nov 14, 2023 · 1 comment
Closed

negative tabindex not working as expected #2917

AHBruns opened this issue Nov 14, 2023 · 1 comment

Comments

@AHBruns
Copy link
Contributor

AHBruns commented Nov 14, 2023

Environment

  • Elixir version (elixir -v): 1.15.7
  • Phoenix version (mix deps): 1.7.9
  • Phoenix LiveView version (mix deps): 0.20.1
  • Operating system: MacOS
  • Browsers you attempted to reproduce this bug on (the more the merrier): chrome
  • Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: Yes

Actual behavior

If you try to use JS.focus to move focus to a non-interactive element with tabindex of -1 it does not move focus to said element. However, if you give the element a tabindex >= 0 it will move focus to the element when JS.focus is called.

Expected behavior

JS.focus should move focus to any element with a tabindex that is negative since a negative tabindex indicates an element which should not be tabbable, but is still programmatically focusable.

@AHBruns
Copy link
Contributor Author

AHBruns commented Nov 15, 2023

Looking into the code, it appears that this is the problem line

(el.tabIndex > 0 || (!interactiveOnly && el.tabIndex === 0 && el.getAttribute("tabindex") !== null && el.getAttribute("aria-hidden") !== "true"))

el.tabIndex === 0 shouldn't be here. I recommend rewriting this line to

!interactiveOnly && el.hasAttribute("tabindex") && el.getAttribute("aria-hidden") !== "true")

The original implementation seems to be conflating an element being focusable with an element being accessible via keyboard navigation which is not the same thing. Additionally, it seems to be treating positive tabindexes as interactive which I believe is a separate bug. Here's an excerpt from MDN explaining the meaning of different tabindex values:

A negative value (the exact negative value doesn't actually matter, usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation.

Note: tabindex="-1" may be useful for elements that should not be navigated to directly using the Tab key, but need to have keyboard focus set to them. Examples include an off-screen modal window that should be focused when it comes into view, or a form submission error message that should be immediately focused when an errant form is submitted.

tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source.

A positive value means the element should be focusable in sequential keyboard navigation, with its order defined by the value of the number. That is, tabindex="4" is focused before tabindex="5" and tabindex="0", but after tabindex="3". If multiple elements share the same positive tabindex value, their order relative to each other follows their position in the document source. The maximum value for tabindex is 32767.

If the tabindex attribute is included with no value set, whether the element is focusable is determined by the user agent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants