Usability and accessibility » Footnotes

Adding footnotes to an HTML document is anything but straightforward. As the standard astonishingly lacks a dedicated tag for this staple of academic writing, finding a usable and accessible design is tricky.

The challenges

As various discussions, implementations and experiments (more in detail further below) illustrate, challenges for designing inclusive and usable footnotes are manifold. In addition to the overall challenge of creating a design that works for everybody, while being aesthetically pleasing (and versatile, in the case of reusable solutions) as well as generally comfortable and intuitive to use is really hard, the devil is in the details as well. Questions to be addressed by a good solution are:

• semantic meaning of the markup in the text (both the clickable element as well as the part the footnote relates to)
• link target size (tiny superscript numbers are very likely to not comply with WCAG standards)
• the necessity to “read with my finger” on expandable or anchor jump footnotes vs. scarcity of screen real estate on small devices
• positioning and potential overlap for sidenotes/marginnotes

Terence Eden has a good user-centric discussion of the “usability of footnotes”, in which he develops some requirements for a footnote design with good UX:

The baseline

Kitty Giraudel presents a solid solution for accessible footnotes that I consider the most robust baseline implementation. Using CSS counters and semantic jump links, this design covers all the basics.

Kitty has also created a React implementation of the code from their article. Elsewhere, a JavaScript implementation for the Hugo static site generator provides an example how to improve on inaccessible markup.

Its only shortcoming in editorial practice appears to be its reliance on parts of the text being linked (the “footnote number” is added to a hyperlinked word or sentence, which is indeed important to create a big enough click target), rather than free-standing footnote markers; while this is great for semantics, for example adding a footnote to an entire paragraph is difficult (or breaks the accessible logic behind the design).

Alternative markup and design approaches

Using the <ruby> element

The <ruby> element is little known (and little supported), but provides an interesting alternative approach. I’d personally not use this in production, but it’s an interesting exploration. Also: why does HTML not have a semantic <footnote> tag?

Displaying footnotes in context

While traditional footnotes work well in print, they are not particularly reader-friendly on the web. Jumping from the reading context to the bottom of a — potentially long — page and back disrupts the reading flow far more than footnotes (often just asides, or even pure references) intend to.

Sidenotes/Marginnotes

The most commonly sought solution to avoid jumping is to display footnotes on a column next to the text body. Referred to as “sidenotes” or “marginnotes” (the latter commonly without a marked indicator in the text), these have been popularized by Edward Tufte’s classic information design books.

There are a few HTML implementations out there, thoroughly researched and presented by Gwern:

The article systematically dissects the nature of footnotes and then evaluates an impressive amount of existing libraries/solutions for footnotes on the web.

In this example implementation by Nils Hörrmann, CSS grid is used to place annotations, separately stored in a data structure, next to the according paragraphs.

Originally found from Gwern’s article, I discovered a few approaches that use a “slide-in” to present footnotes (either one at a time, or all at once with the current one highlighted). As rather unusual patterns, they come with some usability challenges. But the idea is refreshing.

Semantics and experimental markup

No matter their presentation (as footnotes, on the side, expandable or not…), getting the semantics right is tricky, as the most suitable element comes with some limitations as it is a block-level HTML element.

Block vs. inline – or: aside vs small

There is an important semantic difference to be made between <aside> and <small> tags for such implementations. From a semantic perspective, <aside> seems particularly suitable for marginnotes (the Tufte CSS authors acknowledge that but sideline the idea due to a clash with the purely HTML approach; in a progressively enhanced solution, this would likely be significantly easier).

The HTML spec says:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The major design challenge, however, is that an <aside> element will inevitably auto-close an open paragraph, i.e. it cannot be used for a footnote inside a paragraph. That makes it suitable only for marginnotes, and only if not anchored to single sentences but before/after any block element.

The definition of the small element, on the other hand, indicates that it is not really intended for footnotes and the like:

Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.

Footnotes, sidenotes and marginnotes do not really satisfy the requirements for the small element laid out in the HTML spec. Also, the fact that it should not be used for paragraphs and lists limits its applicability.

The details/summary element

Also the <details><summary> markup has been suggested (e.g. here), to tackle display challenges on mobile. Personally, I am not convinced that this is the semantically correct element for most use cases. Also, as Robin Rendle has demonstrated, it being a block element does not really make it fit for purpose; an otherwise exciting experiment by Chris Coyer, building on explorations by Terence Eden leads to the same conclusion.