Recently, someone posted on LinkedIn that skip links are often broken because their target elements are missing a `tabindex` attribute. I was really surprised to see that because I thought that was an issue of the past. That's why I decided to test it.

https://matuzo.at/blog/2026/skip-links-tabindex?d=0503

Update: Thanks for the feedback. I've added more tests and updated the title.

Your skip link targets may not need tabindex=-1 to work properly - Manuel Matuzovic

I'm a frontend developer in Graz, specialized in HTML, accessibility, and CSS layout and architecture.

Manuel Matuzovic

@matuzo Is that what they are called today, "skip links"? Whatever happened to "document fragment"?

Guess I've learned something new today.

@dreddie "skip links" are a specific use of document fragment links, to allow keyboard or screen reader users to skip over large navigation menus & get straight to the content without having to tab-tab-tab through every other link. But they only work for that purpose if the keyboard focus (not just the scroll position) actually moves to the target!

@matuzo

@AmeliaBR @matuzo It sounds to me that it is a band-aid / workaround for something more fundamental to the page. If you page is designed in such a way that large sections can be skipped without affecting the content, then why are these sections on the page in the first place? Just remove them instead. And I sincerly hope that by using the <main> element any assistive technologies have standard hotkeys to jump to that content.

A better way imo would be to provide for example alternate display modes on the page. Many browsers have a Reader Mode built in. The page or site should also contain things like RSS feeds.

@dreddie @AmeliaBR @matuzo Hi! Thanks for bringing this up. Accessibility people have never thought about this. /s

Sorry. This is for skipping the navigation when someone uses the keyboard but no assistive technologies. Yes, browsers could add that functionality natively, but they give a fuck. Thanks for coming to my TED talk on “why sometimes accessibility accommodations need to be made while they could solved otherwise, but that is just not done due to ableism in the web technology space”.

@yatil If your page navigation is in the way of keyboard users, you sould redesign the page so the navigation is NOT in the way of keyboard users.

If there is a large 'table of contents' before the main content, maybe move the TOC to the side of the page. Instead of band-aid solutions like a skip-link.

@dreddie Good idea to have keyboard users navigate through all of the content to get to the table of contents. Oh, what is that? They need a skip link for the content then? Yeah.

(Also a table of contents is also skip links. 🤷‍♂️)

It’s okay to not know or not fully understand, but it’s a bit insulting to give advice to people, who work on these problems for decades. We have thought long and hard about this, skip links are practical, flexible, and easy to implement.

@matuzo FWIW, when I last tested this in early 2025: there was a lingering issue with iOS Safari.

If the target was overlapped by another element (e.g. a sticky header), the skip links didn't work properly without tabindex on the target. And when I say "overlapped," I don't necessarily mean to the degree that the target was obscured.

I tend to still add the tabindex because why not? And also because I'm getting old.

@jscholes As often, I was hoping you would provide feedback, and you delivered. Thank you! 😁

I don't have an iPhone at the moment, but I will test this asap and file a bug, if it hasn't been done yet.

@jscholes
I find `tabindex="-1"` is still needed on the skip link target.

Testing with VoiceOver on macOS 15.7.4+Safari 26.3

- Focus and virtual cursor is on "Skip to content" link.
- Press Enter to activate link
- Press VO+right arrow to move the virtual cursor to next element

If the skip link target doesn't have `tabindex="-1"`, the virtual cursor moves to the next element after the skip link. If the target does have `tabindex="-1"`, to moves to the next element after/within the targeted element, the intended behavior.

If I use VO+Space to activate the skip link instead of Enter, the tabindex isn't needed to work as intended. Even if that's the more common way to activate a link with VoiceOver on, the intended behavior should still be supported when Enter is pressed.

@matuzo

@cwilcox808 @matuzo Good data! Thanks for testing.

In general, VO has quite a few small bugs in the synchronisation between its own cursor and the system focus. Especially when the latter is set programmatically by the page itself.

@cwilcox808 @jscholes Good catch, but I'm not sure I we should/can account for that because there are all kinds of strange behaviors when you use Enter instead of VO + space.

Here are some examples: https://cdpn.io/pen/debug/EagKVrb

Nevertheless, I'll mention it in the post.

Testing VO virtual cursor + Enter

@matuzo I saw that post on LinkedIn and was wondering the same thing. Thanks for doing all that testing!

@matuzo I also blogged a while back about a weird issue in iOS Safari triggered by tabindex=-1 (still not fixed)

https://danburzo.ro/skip-to-content-back-button/

My “Skip to content” markup was breaking the back button on iOS · Dan Cătălin Burzo

<code><main tabindex=-1></code> makes iOS Safari forget its scroll position.

@db Good, to know. Thank you!