Links are essential for navigating any website since the inception of the modern web in the 2000s. There is no specific number expressing the maximum amount of links in any given web-page. However, it is safe to assume that a semantic HTML header will have multiple anchors links. The header after-all is the entry point to your website’s nested structure. Although, crowded navigation might not be as problematic (as the slew of pop-ups and attention seeking advertisements), it can certainly be tedious for some visitors.

Navigating the web without a mouse is not as trivial as one might think. Depending on the website’s implementation, keyboard compatibility might not even be implemented correctly. Interestingly, industry leaders understand the importance of accessibility and the wider population impacted. Therefore, we can observe a well deserved paradigm shift towards a keyboard accessible web.

I encourage you to use your favourite social media network with a keyboard to better understand the underlying issue.

Every time a keyboard user visits a page, they have to TAB through the entire navigation before any meaningful content can be read. User Experience (UX) professionals have commonly identified such issue and addressed it with what is commonly known as a “Skiplink”

Such anchors are meant to be used as the first HTML element that a user can TAB to. They often exist hidden in the the header navigation before other links can be identified. A common HTML implementation might look similar to this:

<header>
  <a class="skip-link" href="#main-id">Skip Navigation Links</a>
  <nav>
    ... more links
  </nav>
</header>

Your SCSS styling can be designed as such:

.skip-link {
    margin-right: 1rem;
    position: absolute;
    transform: translateX(-200%);
    transition: transform 0.3s;

    &:focus {
        position: static;
        transform: translateX(0);
    }
}

By default our Skiplink has position: absolute; to not disturb the flow of HTML. When the keyboard is used to navigate, our .skip-link will gain focus and be inserted back to the static HTML position.

We are using transformX due to its performance when we transition to a focused state. The core assumption leading us to use transform is derived by the header expanding with the viewport. If your header has static dimension it is recommended to use the left property.

Implementational Pitfalls

The aforementioned implementation is sufficient enough for many projects. It will most certainly make keyboard navigation users pleased. However, if you are interested in re-usable and robust engineering infrastructure it is advised to consider the following pitfalls:

1. Re-usability: More often than not, header variations are going to be prevalent in your web application. It is common to have a marketing and a web-app header component serving different needs.
2. Fragment (#) Navigation: Your web application is complex with potentially hundreds of pages sharing a common HTML landmark structure. Implementing an id attribute to match your skiplink’s href can be tedious and error prone.
3. Search Engine Optimisation (SEO): It is inevitable that your anchor link will be parsed by web crawlers. Hiding your Skiplink is not recommended as Google suggests in their authored article about: Hidden Text Links.
4. 

5. React Skiplink

   How can we mitigate all of the above mentioned risks for our web application while catering for the engineers and the users alike?

   We can address fragment navigation by programmatically scrolling to an element using a combination of the document.querySelector() and introducing .focus() on the selected HTML wrapper element.

   SEO can be improved by utilising buttons instead of anchor Skiplinks. Buttons are not easily interpretable by website crawlers, however, our implementation should be invariant.

   Regardless of using buttons or anchors, we want to create a re-usable component that encapsulates our desired functionality. It is evident that we will need an onClick event handler that should be forwarded to our children.

   Our React + TypeScript implementation can be found below:

   import React from 'react';
   
   interface SkipLinkProperties {
       className?: string;
       
       children: React.ReactElement;
       /**
        * The css query aiding the selection of the
        * container (main, section etc) we want to scroll to;
        */
       skipTo: string;
   }
   
   const SkipLink: React.FC<SkipLinkProperties> = props => {
   
       const onClick = (event: React.SyntheticEvent) => {
           event.preventDefault();
   
           const container: (HTMLElement | null) = document.querySelector(props.skipTo);
           
           if (container) {
               container.tabIndex = -1;
               container.focus();
               setTimeout(() => container.removeAttribute("tabindex"), 1000);
           }
       };
   
       return React.cloneElement(props.children, { onClick, className: props.className });
   }
   
   SkipLink.defaultProps = {
       className: "skip-link",
       skipTo: "main:first-of-type",
   };
   
   export default SkipLink;

   The React.cloneElement() is particularly useful in our implementation. We are passing an additional className property that might not be necessary in your own implementation. It is advisable to use that property to keep the class name consistent across multiple imports without relying on the children.

   A potential composition for your own project might look like:

   <SkipLink className="primary skip-link">
       <button type="button">Skip Navigation Links</button>
   </SkipLink>

   The aforementioned SCSS implementation is still applicable.

   Hopefully, Skiplinks get adopted and standardised on a wider spectrum across the web. They are easy to implement while constituently enhancing your website’s keyboard accessibility.