Footnotes have a long and storied history dating back to the Middle Ages. For hundreds of years, they have been a powerful tool for providing information that supplements and supports the main text. By providing an easy way to access source references or additional information, footnotes have withstood the test of time. As a modern example, my personal favorite use of footnotes can be found in the fantasy novels of the late Terry Pratchett, where they are used to provide world-building and character insights in the voice of a hilarious outside narrator.

Just as footnotes can be an incredible tool on paper, they can also do great work on a web page. Clicking on an inline footnote reference can lead readers directly to the supplemental information in the footnote. Once they're finished, it can also take them back to their previous position on the page.

This is easy enough to set up to work with a mouse, but we also want to make sure our lovely keyboard and assistive technology users can reap the benefits of footnotes just as easily.

Accessibility Guidelines

There are some key factors of accessibility to keep in mind when coding up some footnotes:

1. Semantic structure: Using semantic structure provides meaningful and properly organized content that can be interpreted accurately by assistive technologies, allowing users with disabilities to navigate, comprehend, and interact with web pages effectively.

2. Keyboard accessibility: Making websites keyboard accessible ensures that folks who can't use a mouse or rely on alternative input methods can still navigate and interact with them, allowing for inclusive and barrier-free access.

3. Support for assistive technologies: Supporting assistive technologies like screen readers enables people with visual impairments or reading difficulties to access and comprehend web content by converting text and other visual elements into audible or tactile representations.

Implementation

Let's take this one step at a time. Since we're focused on accessibility here, we'll work through the accessibility factors mentioned above.

Semantic structure & keyboard accessibility

Oftentimes, keyboard accessibility can be tackled entirely by using proper semantic HTML. This is one of those cases.

<p>
 This is some example text supported by a footnote
  <a id="footnote-1-link" href="#footnote-1">
   <sup>[1]</sup>
  </a>
 .
</p>


<ol>
 <li id="footnote-1">
  Footnotes provide supportive information.
  <a href="#footnote-1-link">↩</a>
 </li>
</ol>

1. The link to the footnote (ex. "[1]") is contained by a <a> tag.

2. The <a> tag has a unique id attribute and an href attribute set to the id of the footnote it links to.

3. The <a> tag wraps a <sup> tag. You're probably wondering "What's <sup>, dog?" "Sup" is short for "superscript," meaning the text is small and raised to the top of the line height. This is the recommended presentation for footnote links, ideally consistent across the web.

4. The footnotes at the bottom of the page are contained in an <ol> tag since the order of the footnotes matters.

5. The <li> tag containing the footnote has a unique id attribute, matching the href attribute on the footnote link.

6. The footnote <li> tag contains a <a> tag that links back to the corresponding footnote link. The href attribute matches the id attribute of the footnote link. If multiple footnote links lead to the same footnote (like if one reference is used in multiple places on a page) JavaScript will be required to dynamically change the href attribute of the link in the footnote to take users back to where they came from.

Support for assistive technologies

Using semantic HTML already takes us pretty far when it comes to supporting assistive technologies like screen readers and refreshable braille displays. But we can do better by increasing the clarity of our footnote links and "back to content" links. The code example below is mostly the same, but there are a few important changes.

<p>
 This is some example text supported by a footnote
  <a id="footnote-1-link" href="#footnote-1">
   <sup>[1] <span class="sr-only">Footnote details</span></sup>
  </a>
 .
</p>


<ol>
 <li id="footnote-1">
  Footnotes provide supportive information.
  <a href="#footnote-1-link" aria-label="Back to content">↩</a>
 </li>
</ol>

1. Add a <span> tag inside of the <sup> tag with a description of where the footnote link leads, such as "footnote details." This way, screen readers will read out more than just "one" for the link. Use CSS to hide this text visually but keep it on the page for screen readers and other assistive technologies.

2. In the above example, the "back to content" link in the footnote is displayed as an icon (↩). This isn't readable by screen readers and other assistive technologies, so we can give it a text alternative with the aria-label attribute.

Outroduction

Now we know how to make accessible footnotes! To summarize:

1. Use proper semantic HTML with tags like <a> and <sup>.

2. Use matching href and id attributes on footnote links and "back to content" links.

3. Improve the experience for folks using assistive technologies like screen readers by utilizing "screen reader only" CSS and the aria-label attribute.

For more information about accessible footnotes, check out the footnotes section of Hyah UI.

Have a question about how to implement any of the above steps? Or maybe you've caught something you think is missing or incorrect? If any of that sounds like you, comment down below so we can chat about it!

If you're in the majority of users (statistically speaking, you probably are), you can look at a page as soon as it loads and start viewing the main content right away. By automatically ignoring the elements that are present on all pages of a site (header navigation, left-side ads, etc), you can dive right into what brought you there in the first place. Grab hold of your mouse and click right on the button or link you want, regardless of where it is on the page.

Unfortunately, many users aren't able to do this. Some examples are:

• Users with low vision, blindness, or a cognitive disability may use a screen reader to navigate the web, which reads out elements on web pages one at a time.

• Users who have difficulty making the precise movements necessary to use a mouse may primarily or exclusively use a keyboard to interact with the web, using the Tab key to move through each interactive element in order. Many power users also use keyboards to navigate web pages or web applications quickly.

Without the ability to jump to the part of the page they wish to engage with, they have to start at the top and work their way down every page. That's so dang tedious!

This issue is the reason behind WCAG Success Criterion 2.4.1: Bypass Blocks, requiring that "a mechanism is available to bypass blocks of content that are repeated on multiple Web pages."

Luckily for us, there is a simple way to account for this: the "Skip Navigation" or "Skip to Main Content" link.

A "Skip Navigation" link sits at the top of a web page as the very first interactive element. Before proceeding into the page's header elements and nested navigation menus, they have the option to skip past that nonsense and get to the juicy main content.

How do I make a "Skip Navigation" link?

The steps for creating great "Skip Navigation" links are straightforward:

1. Give the main content an id.

2. Add a link to the top of the page that targets the main content.

3. Use JavaScript to change focus (if necessary).

4. Hide the link with CSS.

Give the main content an id

For the "Skip Navigation" link to know where the main content is on the page, we need to give it a unique identifier that the link can target. This is done by slapping an id property on the wrapping element.

<main id="maincontent">
...
</main>

It's recommended that your page uses a <main> element to wrap the main content of your page so that assistive technologies like screen readers can identify it. That's a topic for a different article, so we'll leave it at that for now.

Add a link to the top of the page that targets the main content

Now that we have a way for our new link to find the main content, we need to add said link to the page. This will be an <a> element with an href property set to the id of the main content (see the previous step), preceded by a #.

<a href="#maincontent" id="skiplink" class="skiplink" >Skip to Main Content</a>

Activating that link will take the user to the main content, skipping past that pesky navigation menu so they can slurp up that sweet sweet main content. Yum.

Note: The text in the Skip Navigation link must be straightforward to understand quickly since this is all about getting users where they need to go faster and more conveniently. With that in mind, it is recommended that the text used for the link is either "Skip Navigation" or, my personal preference, "Skip to Main Content."

Use JavaScript to change focus (if necessary)

Activating our cute little "Skip Navigation" link takes us to the correct spot on the page now, but sometimes that isn't quite enough to get the job done. Depending on the browser and the setup of the page, the focus may not have moved to the main content like we want. Using JavaScript we can make sure that activating the link also moves focus past the unwanted elements.

First, we need to make sure the main content wrapper is focusable by giving it a tabindex property. We don't want it to be added to the page's tab sequence though. If we set the tabindex to -1, the element becomes focusable but doesn't exist in the tab sequence. Perfection.

<main id="maincontent" tabindex="-1">
...
</main>

Next, we just add an event listener to the "Skip Navigation" link so the focus is correctly moved whenever it is activated. We can use the focus() function on the DOM Node class to accomplish this.

const skipNavLink = document.querySelector("#skiplink");

skipNavLink.addEventListener("click", () => {
  const mainContent = document.querySelector("#maincontent");
  mainContent.focus();
});

With that, clicking or pressing Enter on the "Skip Navigation" link will jump the user to the main content and ensure that the keyboard focus has skipped all prior elements in the tab sequence!

Hide the link with CSS

Whoa whoa whoa whoa whoa. "Hide the link?" Didn't we just go through the trouble of making it? Why would we hide it?!

Well, hear me out.

Yes, we have this incredibly useful link that improves the experience of lots of our users. But what about the majority of users who don't need it? There's no reason to clutter up the UI with links most people don't need. Thus, we hide it!

Using CSS, we can hide the "Skip Navigation" link by default, and only display it when it's needed. Translation: if the link isn't focused, we don't need to see it.

There is a plethora of ways to accomplish making the "Skip Navigation" link only visible when focused. Here is one:

.skiplink {
  position: absolute;
  left: -9999px;
  opacity: 0;
  z-index: 1000;
}

.skiplink:focus {
  left: 50%;
  transform: translateX(-50%);
  opacity: 1;
}

As I said, this is just one way of conditionally hiding the link. The important part is that it's completely hidden by default, and is visible when focused.

Also, while you're in the CSS, you might as well style up your link to look just as rad as the rest of your site! The users who need this link must have the same quality experience as other users. Everyone deserves to see your killer designs!

Conclusion

So there you have it. Now you have a dope as heck "Skip Navigation" link that improves the experience of any user of your site that doesn't use a mouse.

Have a question about how to implement any of the above steps? Or maybe you've caught something you think is missing or incorrect? If any of that sounds like you, comment down below so we can chat about it!

Boy, do I love websites with great imagery. Pictures of landscapes. Pictures of cats. Pictures of pictures. Pictures of graphs. Putting images on a site can make it miles more interesting.

That's not the only thing great about using images, though. People with low-vision or a cognitive disability may find it difficult to read or process text on its own. Supplementing text content with a picture or graphic is great for helping all users experience what your site has to offer. Plus, images let me insert pictures of my dog Mayari anywhere I want. Like so:

So, yeah, images are pretty dope. But with great imagery, as they say, comes great responsibility.

The Rising Action (Why?)

Images can cause pretty unfortunate performance issues when used without care (anyone who knows their way around Google Lighthouse knows what I'm talking about). Most notably, images can have a significant impact on a page's Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS).

When a webpage is loading, a single prominent element can cause users to believe the entire page is slow even if every other element is ready to rock. It doesn't matter if 90% of your site is lightning-fast if your hero photo takes two seconds to appear. It's not until they see the picture that users believe the page is just about ready to be useful. The measurement of how bad this is is called the Largest Contentful Paint or LCP. LCP is the amount of time that passes before the largest area of the screen is rendered. Since image elements are often used at the top of pages to quickly grab users' interest, not optimizing them for performance can cause users to believe the site is too slow and leave.

Have you ever tried to click on a link right after a page loads only for the button to jump down causing you to click on an ad for travel insurance instead? You just experienced a high Cumulative Layout Shift or CLS. CLS is the quantification of how often users experience unexpected shifts on the page. Poorly handled images can cause these infuriating gotchas by spontaneously appearing and taking up space.

Having high LCP and CLS scores can have a significant negative impact on user stickiness/session duration. Luckily, there are some things we can do to ensure our users don't have to wait for that sick banner photo of a dog catching a frisbee.

The Climax (How?)

Use the best format

I'm gonna make this easy for all of us. If your image names don't already end in .webp, then fixing that is the first step. WebP offers all the benefits of the classic formats we know and love (looking at you, PNG and JPEG), but they're much better at lossy and lossless compression. What that means for you is that they're generally harder, better, faster, and smaller.

There are a ton of super easy ways to convert your existing images to WebP. Google "convert image to WebP" and take your pick. If you have an absolute ton to convert or want more granular control though, you can do it scriptomatically. I made my tool for converting and optimizing images (check it out) in Node using the npm package sharp.

Compress

Believe it or not, images on a web page can be too good. If an image is so high-resolution that you can make out each grain of sand in the sandcastle you built with your niece, it's way too high. The bad news: you need to compress that image. The good news: no one will notice if you do it right.

Compressing your images can be as easy or as hard as you want. If you have a small number of images to compress, find a compressor online and drop them in. Typically you'll need to designate what level of quality you want. In this case, I recommend some good old-fashioned trial and error to find how much you can compress your image without a noticeable loss in quality. You can also do it scriptomatically, like I did here.

If you're set on going deep into image compression, you'll find there are multiple different algorithms and philosophies on how best to do it. Delving into that is more than I've ever needed, but I'm sure some of you have or will get down and dirty with it.

Use responsive image tags

Go ahead and let those pants out an extra inch 'cause this part is a bit beefy.

It truly, truly is not necessary for a mobile user to see the same size picture as a desktop user. Mobile devices typically take much longer to load images, and I promise that no one is going to zoom in close so they can see how many freckles you have. For this reason, we might as well have users on mobile devices see a smaller version of the image so they don't have to wait for the bulky desktop version. Images that behave differently based on screen size are called "responsive images."

HTML offers everything we need to serve responsive images, with no fancy-pants JavaScript required. There are a few ways to do it though, and it's important to know when to use each method.

1. When the image is small enough to not need responsiveness

   • Use this for stuff like logos or icons that are always the same size. This method is what most of us are used to. Nice and safe.

       <img src="/assets/sandcastles_in_the_sand.webp"
            alt="An impressive sandcastle the author built with his niece. Features battlements and a moat."
            width="200" height="150"
       >
     

2. When the image needs responsiveness, but always looks the same

   • Make use of the srcset and sizes attributes.

   • src points to the version of the image to use if the browser doesn't support srcset (pretty much just Internet Explorer).

   • srcset lists all the images the browser can choose from, paired with each image’s width.

   • sizes holds the rules for when to display the images listen in srcset. A media condition followed by a size that corresponds to one of the images in srcset.

       <img
           src="puppy-doggy-900w.webp"
           alt="An overwhelmingly cute Irish setter puppy with red hair."
           srcset="puppy-doggy-600w.webp 600w,
                   puppy-doggy-900w.webp 900w,
                   puppy-doggy-1200w.webp 1200w,
                   puppy-doggy-1200w.webp 1200w, 2400w"
           sizes="(max-width: 600px) 600px,
                  (max-width: 900px) 900px,
                  (max-width: 1200px) 1200px,
                  2400px"
           width="900" height="900"
       />
     

3. When different images need to be shown based on screen size

   • Use the <picture>, <source>, and <img> tags, along with the media and srcset attributes.

   • The browser picks the image URL to use from srcset, based on the first <source> with a media attribute value that matches the user's viewport width.

   • <img> will be used as a fallback if <source> isn’t supported.

       <picture>
           <source media="(min-width: 45em)"
                   srcset="big-wolf.jpg"
                   width="600" height="600"
           >
           <source media="(min-width: 32em)"
                   srcset="medium-wolf.jpg"
                   width="400" height="400"
           >
           <img src="small-wolf.jpg"
               alt="A wolf scampers menacingly through the snow."
               width="300" height="300"
           >
       </picture>
     

Lazy loading

Ok, talking about responsive imagery was a whole meal. Luckily, this next part is a snack.

When you visit a webpage, the browser asks and (hopefully) receives instructions about what to put on the page and how to do it. Then, it asks the server if it would please send over those images mentioned in the instructions it kindly shared. Instead of waiting for an immediate response (sometimes servers, like people, take a bit to get back to you), the browser presses on. Once it's ready to start painting on the content, it starts from the top and moves its way down to the bottom.

As we've discussed already, sometimes images take a sec (hopefully less) to render in. If an image is so big (or a server is so slow) that it still hasn't arrived by the time the browser wants to paint it in, the entire show stops and waits for it. Then users and Google Lighthouse all get upset.

But, because the page renders top to bottom and screens are only so big, we don't need to make users wait for all of the images on a page. If there's an image of a logo in the footer, we can tell the browser to not hold everything up. I know, that logo designed by your sister-in-law's dog groomer looks so professional and perfectly represents your brand. Everyone will appreciate it more if they don't have to wait for it.

If an image doesn't need to be displayed right away, the solution is easy. Slap loading="lazy" on that bad boy. This tells the browser not to wait, to keep calm, and carry on serving up the page.

<img src="vape-store-logo.jpg" loading=“lazy” alt="Victors Vapes logo." width="150" height="100">

Give all images width and height

Now, back to those pages that jump up and down as they load. We chatted for a bit about Cumulative Layout Shift (CLS) already. CLS from images can easily be addressed by slapping width and height attributes on your images. This will tell the browser how much space to put aside so that the image has room to pop in when it's ready.

<img
    src="sandcastles-in-the-sand.webp"
    alt="An impressive sandcastle the author built with his niece. Features battlements and a moat."
    width="200" height="150"
>

The Falling Action (Summary)

As we've discussed, images are magnificent in how they can make websites more interesting and accessible, but they can also cause performance issues. To ensure the best experience for your beloved users, make sure your images:

1. are in WebP format.

2. are compressed.

3. are responsive.

4. are lazy-loaded

5. have width and height attributes.

The Denouement

There you have it! I hope this information was helpful for all y'all using images to enhance your site's experience for your users.

Have a question about how to implement any of the above recommendations? Or maybe you've caught something you think is missing or incorrect? If any of this sounds like you, comment down below so we can chat about it!

My Node image optimizer

Google Lighthouse