• Imagining Native Skip Links
  • Kittygiraudel.com
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Proofread by: Chzh9311, Kimhooo

[We recently talked about “skipping to content” links in our A11y Advent Calendar topic. If you’re not familiar with the concept, let me quote from there:

When a link is clicked, the page is reloaded and the focus returns to the top of the page. If you use accessibility to navigate a page at this point, you have to skip the entire header, navigation, and sometimes even the sidebar before you can get to the main content. What a terrible experience! To solve this problem, a common design pattern is to implement a skip link, which is an anchor link sent to the main content area.

Existing problems

So it’s all good. Just jumping to the content link implementation is not that simple. To list just a few of the constraints it should satisfy:

  • It should be the first link recognized by accessibility.
  • It should be carefully hidden so that it is still available to specific users.
  • It should become visible when focused on it.
  • Its content should start with “skip” to make it easy for the user to identify.
  • It should navigate to the main content of the page.

It’s not complicated, but it’s easy to screw up. Since every website needs to do this, the question arises – why don’t browsers support it natively? I proposed this to Web We Want back in December.

Browser functionality?

It’s not hard to imagine that in order to provide a better, more consistent experience for people using assistive technologies, browsers could handle this problem natively, requiring little control from web developers.

When you jump out of a TAB in the browser’s user interface (or use a dedicated shortcut key to switch) and go to another page, the browser immediately displays the skip link and makes clear:

  1. It will be inserted as the first element in the label order.
  2. It will use the browser language, not necessarily the web page language.
  3. Technically, it will be part of the browser interface, not part of the website. Therefore, this will be styled according to the theme of the browser.
  4. It is not intentionally accessed by web pages (strictly speaking).
  5. It will be rendered at the top of the page to avoid the risk of ruining the layout.

An HTML API

The central idea is to minimize control over it. Just as developers have no say in how browser tabs or address bars look and behave. That is, the destination of the link should be configurable.

A reasonable default is to point to the


element, because it is unique within each page and explicitly contains the main content.


is the main content of the document or application body. The main content area consists of content that is directly related to or extends the central topic of the document or the central functionality of the application.

  • W3C HTML editing draft

But not all sites use the


element. I think browsers might have some built-in heuristics for figuring out what the main content container is, but I’m afraid that’s beyond the scope of this feature.

So, to give Web developers a way to define exactly which container is the true master container, use a
tag. It will accept a CSS selector (complexity depends on the requirements), and when using the skip link, the browser will query the DOM node, scroll and focus it.

<meta name="skip-link" value="#content"/>
Copy the code

Another approach is to use tags with rel attributes, as Aaron Gustafson suggested.

<link rel="skip-link" href="#content"/>
Copy the code

Whether the browser should listen for changes to this element (whatever it is) is an open question. I think so, just to be on the safe side.

What should be done with existing jump content links?

Will browsers implement skipping links locally, and what will happen to our existing custom links? They probably won’t be too bothered.

Tabs in the content area of the web page will display native jump links. If used, it bypasses the entire navigation, including custom jump links. If not, the next TAB will be a jump link to the site, which will be redundant but irrelevant.

Ideally, browsers provide a way to know if they support this feature, so jump links can be multiple populated for browsers that don’t yet support jump links. But this will most likely require JavaScript.

if(! windows.navigator.skipLink) {const skipLink = document.createElement('a')
    skipLink.href='#main'
    skipLink.innerHTML = 'Jump to main content'
    document.body.prepend(skipLink)
}
Copy the code

finishing

This is by no means perfect, nor do I have a foolproof solution to offer. If there were, I’m sure someone smarter and more knowledgeable than me would have mentioned it.

Still, the lack of jump links is a big hurdle for people using assistive technology to navigate the web. And given that every site needs one, and there is little difference between sites, it does feel like something that browsers should do natively.

As always, feel free to share your thoughts with me on the nuggets community 🙂

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.