Accessibility issue with focus

[smustgrave]

When a tour is started the focus should appear on the close button but currently it's lost.
When you press tab once after starting focus still doesn't appear. It's not till after you press tab a second time do you see focus.
This introduces an accessibility problem

[RobbieTheWagner]

@smustgrave could you please point me to some documentation that says the close button should be focused first?

[smustgrave]

https://help.siteimprove.com/support/solutions/articles/80001050116-accessibility-rule-keyboard-focus-indicator-is-missing-explained
https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html

Anything googled about focus being lost

[smustgrave]

Now it doesn't have to be the close button but when a modal opens focus needs to be present. Currently have to tab 3 times to get it back

[RobbieTheWagner]

@smustgrave I think we focus the whole tooltip as the first thing, so if you tab twice it will go to the close button on our demo https://www.shepherdjs.dev/. It then correctly focus traps inside the tooltip and cycles through the elements. I don't think there is a bug here.

[smustgrave]

So on the demo when I start it

Initial load = no idea where focus is
Press tab = no idea where focus is
Press tab again = now on close

The focus tap is correct but on initial load and that first tab definitely feel its an accessibility issue

[RobbieTheWagner]

@smustgrave having no idea where focus is does not necessarily mean it's not focused correctly. My guess, without diving in too deep is it's focused to the dialog and then focused to the shepherd tooltip wrapper element, and then it goes through the stuff inside.

I do not disagree that it's not ideal to press tab an extra time or two though. If you have a solution in mind, we're always accepting PRs!

[rpkoller]

I've just tested the demo on https://www.shepherdjs.dev in Safari 18.1.1... the focus is there. but the problem in my case is the focus is not within the dialog modal but in the background of the modal as you can see in the video

Screen.Recording.2024-12-04.at.22.06.48.mov

in firefox developer the initial focus is the modal and the tabindex is limited to modal, same for edge. i guess the initial "invisible" tab might be due to the fact that the shepherd demo doesnt have a custom outline styling. edge for example has a black focus outline which is invisible against the black dialog modal border. for firefox it is better visible but not that good

[RobbieTheWagner]

@rpkoller thanks for the video. This is interesting because we definitely have tests for making sure focus trapping is working, so I am confused what is happening here.

[smustgrave]

That's actually new for me too. The trap seems to work my only issue is that focus is lost.

[rpkoller]

apologies, i tend to miss the github notification mails for new comments. :(

@rpkoller thanks for the video. This is interesting because we definitely have tests for making sure focus trapping is working, so I am confused what is happening here.

one aspect that might cause or at least contribute to this problem is the fact that the modal is not an actual modal. you have changed the wrapping element from a div to a dialog element in #2959 - thanks for that and your last answer and that the issue got committed als slipped through, i have just too many github notifications coming in :( ).

firefox.mp4

as you can see in the devtools the dialog modal is open but if you are taking a look at the state of modal, it is not available/set. and if you open the rotor in voiceover, elements in the background are still included in the accessibility object model. and due to the fact that the dialog modal is not a modal that might be reason why the focus behaves like it does in my previous video for safari? is the modal in shepherd opened with the show() method? cuz for becoming a real modal the dialog has to be opened by the showModal() method (and according to that article https://blog.webdevsimplified.com/2023-04/html-dialog/ the open attribute wouldnt be necessary as well here https://github.com/shipshapecode/shepherd/pull/2982/files#diff-5397cc28b05b73b4644fb705ecac323a4be2c90722b6117dc31654240862f103R144 or might be even counter productive?)

That's actually new for me too. The trap seems to work my only issue is that focus is lost.

in which browser are you working? and is the close button into focus to you the second time you press the tab button? or are you unable to reach the close button at all, meaning the focus is lost for you completely and the tabindex starts at the top of the DOM?

[smustgrave]

So I haven't hit the focus trap issue but will definitely rely on rkollers feedback.

My only issue has been the focus

[gaddman]

Wouldn't it make more sense to focus the Next button? It's already coloured as if it's focussed, and since the Escape key closes the dialog this would make keyboard navigation simpler: hit Enter to p;roceed to the next tip and Escape to quit . Tabbing to focus a button would then only be needed for going back to the previous tip.