I want a native implementation or API for skip links

[aarongustafson]

Skip links are an important accessibility feature to improve keyboard navigation.
They are also non-trivial to build; they usually need to be visually hidden and revealed only on focus. This is a challenge in CSS since there is no elegant way to do it with a single property. They can also be difficult to integrate in existing web designs and layouts.

It would be good to have browsers implement skip links natively. This way, more websites would have skip links, which would drastically improve overall keyboard navigation, and avoid problematic or buggy implementations. Additionally, they would be normalized across websites, automatically in the right language (browser language) and implemented in the browser UI instead of within pages.

Now figuring out what DOM node is the appropriate container for the main content of the page can be tricky. If that’s not something the browser can easily figure out, this could be provided by the implementor through a meta tag. For instance:

<meta name="main-content-selector" content="#main">

---

https://webwewant.fyi/wants/5fc8bb41d84cfbab3fb47320/

[carmacleod]

Skip links are great, but native landmark navigation would be even better! :)

[aarongustafson]

Landmarks are definitely relevant here too. I linked to your want from this one and will do the inverse as well.

[fuzzbomb]

If browsers provided a way to navigate landmark regions, then skip-links would be redundant.

Right now, skip links are important because they are pretty much the ONLY reliable way to address WCAG Success Criterion 2.4.1 Bypass Blocks, in a way that will help sighted keyboard-only users (not using a screen reader).

I'd say landmark navigation in browsers is far preferable to a native skip-link implementation, and we don't need both.

[aarongustafson]

Another relevant topic here is the age-old link[rel] approach that identified the element containing the license, for example. There were also navigational links for the previous and next pages, top, a table of contents, etc. I believe early versions of Opera supported that navigation out of the box. Firefox, as I recall, had an extension that enabled that support too. Too few sites implement the feature though, which is why (I believe) they’ve kinda fallen by the wayside.

ARIA landmarks (implicit or explicit) to the main content, primary navigation, and search would be the ideal solution IMHO (and @carmacleod’s), but having corresponding rel definitions for some of the key page bits might provide a decent fallback for sites that may not be able to control the full markup.

[aarongustafson]

Actually link[rel="search"] already exists.

[carmacleod]

Actually link[rel="search"] already exists.

Interesting. Do you know if any user agents do anything special with that today?

[aarongustafson]

I don't think so, but @travisleithead may know.

It seems like if it’s present and is an internal document reference, it could be mapped to the ARIA “search” landmark.

[fuzzbomb]

Seamonkey still has a toolbar which exposes link[rel] to users. It can be turned on in the application menu at "View > Show/Hide > Web Navigation Bar".

Finding a site with TOC/next/prev links is uncommon, but the toolbar is handy for some other things. You can still find RSS feeds this way! Most leading browsers have removed that feature. rel=canonical is also sometimes handy to find.

It becomes a bit unwieldy when there are a lots of links which aren't likely to be worth navigating to as a user. For example, the toolbar exposes things like dns-prefetch links to Google fonts, manifest files, and a ton of site icon sizes. It ought to be a good way to find translation alternatives, but sadly a lot of sites neglect to provide a human-readable title for those links.