Bug 258807 – Fragment URL targeting custom element with ID would skip over focusable elements inside shadowDOM

• Component: Accessibility
• Status: NEW

[Tanel Terras]

When activating fragment URL that points to custom element with shadowDOM the sequential focus navigation starting point (https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment:sequential-focus-navigation-starting-point) is set so that any focusable elements in custom element will be ignored.

Everything seems to be by the spec when testing out simpler use-cases: https://codepen.io/hidde/pen/QvKGqa
I created a more complex example that reproduces the bug: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7

Although my target (#content) is custom element it should (to my understanding) not skip over the focusable elements inside custom elements shadowDOM.


Latest chrome and firefox would not skip over the focusable elements inside shadowDOM.

[Radar WebKit Bug Importer]

<rdar://problem/111684394>

[Ryosuke Niwa]

I'm having a trouble understanding what the reported bug is. What are exact steps to follow & what you're expecting to see vs. what you see instead?

[Tanel Terras]

Sorry for not explaining the steps to reproduce.

Please follow the steps in this example: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7

1. Click on the link "Content 2"
2. Press Tab to see keyboard focus
3. Focus shifts straight to green button that is inside #content-3 , skipping two green buttons inside #content-2

I would expect that after step 2 I would see the focus on the first green button inside #content-2.

I refer to #content-2 and #content-3 as custom elements (regular-content) with their own shadow DOM.

Following these steps in chrome/firefox would work as expected - focus in step 2 would shift to first green button inside the #content-2.

[Ryosuke Niwa]

(In reply to Tanel Terras from comment #3)
> Sorry for not explaining the steps to reproduce.
> 
> Please follow the steps in this example:
> https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7
> 
> 1. Click on the link "Content 2"
> 2. Press Tab to see keyboard focus
> 3. Focus shifts straight to green button that is inside #content-3 ,
> skipping two green buttons inside #content-2
> 
> I would expect that after step 2 I would see the focus on the first green
> button inside #content-2.
> 
> I refer to #content-2 and #content-3 as custom elements (regular-content)
> with their own shadow DOM.
> 
> Following these steps in chrome/firefox would work as expected - focus in
> step 2 would shift to first green button inside the #content-2.

Hm... as far as I've checked, Firfox and Safari behave the same and both moves the focus to the button inside #content-3. If wanted the behavior you're desiring, then yo should probably be setting "delegatesFocus" to true when creating the shadow root.

[Tanel Terras]

Created attachment 468230 [details]
Chrome (Stable)

[Tanel Terras]

Created attachment 468231 [details]
Safari 17

[Tanel Terras]

Sorry for the very delayed response.

I have updated my example with delegatesFocus: true. It seems that this has no relation with the specific bug.

I have attached the difference in browser implementations that can be observed when following the steps:

1. updated example: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7?branch=delegatesFocus%40a7ImxJuv82MsKw89cF9BjqxK6XP2
2. Click on the link "Content 2"
3. Press Tab to see keyboard focus

Safari seems to ignore the focusable elements inside my custom element shadowDOM when setting/updating the focus navigation starting point.