theKashey / focus-lock

Gotcha! A11y util for scoping a focus.
MIT License
169 stars 17 forks source link

elements with contenteditable seem to behave as though they have a larger tabIndex #71

Open alex-e-leon opened 4 months ago

alex-e-leon commented 4 months ago

When running autofocus on a collection of focusable items - contenteditable items seem to take priority over other items, unless you manually set the tabindex on it to 0.

I've only tested in chrome, so I'm not sure if this behaviour is reproducible in other browsers.

I think the default behaviour should be that contenteditable items have the same priority as other focusable items?

theKashey commented 4 months ago

Content editable has a little fucked tabIndex (#55) and was not focusable at all. Sounds like now it's on the side.

Thanks for reporting the problem 👍

alex-e-leon commented 4 months ago

Yeah, I figured this was a browser issue - not sure whether it's worth fighting the browser on this one or not, but 2 options I can think of:

alex-e-leon commented 4 months ago

Seperately, while working through this, I also noticed that focus-lock seems to prioritize autofocus on items with tabindex -1, however a tabindex of -1 is supposed to mean as far as I'm aware that the item should not be tabbable with the keyboard, so I would expect autofocus to skip these items.

Not sure what your thoughts are on this @theKashey (or if this should just be a seperate issue) but thought I'd share as well. In my case I've worked around this issue by setting data-no-autofocus, but it was another place where the out of the box behaviour caught me by surprise

stale[bot] commented 2 months ago

This issue has been marked as "stale" because there has been no activity for 2 months. If you have any new information or would like to continue the discussion, please feel free to do so. If this issue got buried among other tasks, maybe this message will reignite the conversation. Otherwise, this issue will be closed in 7 days. Thank you for your contributions so far.