With you on time and with full understanding of how SFN(SP) works 🙂 “Lost” doesn’t presume permanence. SFNSP here makes the *next* move work. Sticking with ‘tabindex=“-1”’ on a non-interactive target makes the the *current* move work.
You're absolutely right that `:target` does work in that scenario, as you mentioned in the article. Default focus indicators do not, though. Sounds like needing to add `:target` CSS to provide a visual indicator so that the HTML can avoid having an attribute. Feels less robust, no?
I did read the post, in full, Manuel. I appreciate the length you went to, to test this. To illustrate that it is a loss of focus, you can watch `document.activeElement`. Here's a quick CodePen that shows that value in the corner: codepen.io/jsnmrs/pen/K.... You're right about `:target`.
From a sighted keyboard user perspective, the need to press tab after following a link sometimes and not others to have an indication of where focus is, isn’t awesome.
The explicit ‘tabindex=“-1”’ avoids that situation.
The focus moves to the ‘<body>’ before the additional tab moves focus to a logic location. It’s essentially a loss of focus until there is another interaction. What would a screen magnifier that follows focus do in that situation?
