You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both swup and the scroll plugin don't explicitly move focus when a same-page anchor is clicked. Focus remains on the clicked link, which is not great for keyboard and screen reader users.
Move the focus navigation starting point to the targeted anchor. Browsers these days don't directly focus the target element but merely move the focus starting point so the next tab press will find the closest interactive element to focus. Technically, the document's active element will be body – the browser merely bookmarks a position for restarting focus navigation.
There's currently no way of manually setting the focus starting point without also focussing the element itself. There's a few workarounds, though, like the one below from a whatwg discussion on the topic. Given the amount of new code required for a "clean" implementation, I'd rather have this in the accessibility plugin than the core.
Describe the problem 🧐
Both swup and the scroll plugin don't explicitly move focus when a same-page anchor is clicked. Focus remains on the clicked link, which is not great for keyboard and screen reader users.
We've briefly discussed the topic on an issue about the
:target
pseudo-lement but I never followed up on checking our implementation.Describe the propsed solution 😎
Move the focus navigation starting point to the targeted anchor. Browsers these days don't directly focus the target element but merely move the focus starting point so the next
tab
press will find the closest interactive element to focus. Technically, the document's active element will bebody
– the browser merely bookmarks a position for restarting focus navigation.Some research or prior discussions:
There's currently no way of manually setting the focus starting point without also focussing the element itself. There's a few workarounds, though, like the one below from a whatwg discussion on the topic. Given the amount of new code required for a "clean" implementation, I'd rather have this in the accessibility plugin than the core.
Alternatives considered 🤔
We could get away with just calling
.focus()
from the core, but that tends to come with styling issues.How important is this feature to you? 🧭
Would make my life a lot easier
Checked all these? 📚
The text was updated successfully, but these errors were encountered: