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:
Footnotes are a weird skeuomorph hangover from the days of printed text. I don't think they are really suited to eBooks - but they seem to have come along for the ride into the future.
Terence Eden highlights how problematic currenty implementations of footnotes – often directly resembling the ones known from traditional print media – are for UX in digital (with a lens on ebooks, but very much transferable to websites as well).
There is no final proposal for a solution in this text, rather a valuable collection of design drivers and some possible leads for designing "better footnotes":
Perhaps authors need to realise that linear text is a relic of paper-based publishing and that hypertext affords new ways for a reader to journey through a text.
The discussion in the comments also contains some really interesting food for thoughts.
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.
This is the benchmark "Tufte style" implementation in CSS. Interesting for its reconstruction of Edward Tufte's iconic typography and layout, but particularly for the creative sidenotes and marginnotes implementation – strictly aiming for a "CSS-only solution", they use a workaround for placing the notes.
Sidenotes are implemented using an empty <label for="sn-in-his-later-books" class="margin-toggle sidenote-number"></label> element with the number assigned using an ::after pseudo-class using a CSS counter. The label toggles a checkbox following right after with <input type="checkbox" id="sn-in-his-later-books" class="margin-toggle"> (it is not quite clear what that checkbox does?). The sidenote itself is then wrapped into a <span class="sidenote"> element, again with the CSS counter's number displayed using a ::before pseudo-class.
For marginnotes, the same technique is used, but the mark in the text is using <label for="mn-blue-links" class="margin-toggle">⊕</label> instead of a CSS counter and is hidden by default if the viewport is wide enough to show the note in the margin. The hidden checkbox is identical, and the marginnote itself is wrapped in <span class="marginnote"> but without the CSS counter.
On narrow viewports, the notes are hidden by default (CSS display: none) and become visible when the hidden checkbox is toggled by clicking the <label> element – this is pure CSS, as it uses a .margin-toggle:checked + .sidenote, .margin-toggle:checked + .marginnote selector.
There has been some discussion about the semantics used in the Tufte CSS, where the maintainer stated, despite general sympathy for the idea to consider accessibility etc., that adding additional markup for accessibility would add extraneous technical complexity to the example code and is hence not part of their MVP (I understand the point of sticking to the set goals of their project, while respectfully disagreeing with this stance (cf. this quote), as I consider full #a11y compliance particularly important when publishing such a template intended for re-use). As using the <aside> element instead is ruled out due to being a block element that cannot be inlined, some ideas mentioned in the discussion are adding role="note" and there is a discussion on whether the <small> tag would be appropriate. Other tickets also refer to these challenges and indeed it seems that the Tufte CSS solution, while very suitable for their defined project goals, are not necessarily the most ideal solution in terms of a11y or UX (depending on project circumstances).
[…] on the right you see footnotes, captions and links? Say again, links? Yes, we figure that it would be nice to show where a link points to so you don’t have to hover.Therefore, we treat links like footnotes. Or better: Sidenotes. There is room for improvement on mobile, but for now we put the footnotes reference on the bottom and scroll you right there.
Anrew Pilsch presents his solution of progressively enhancing Markdown-generated footnotes (with jQuery). Discussing the rationale behind the design, this blog post also refers to the UX challenge of having to "read with your fingers" when footnotes are made expandable on click (for reference mentioning the Bigfoot implementation).
To solve this problem, the proposed solution is to display footnotes in a sidebar when there is space (to provide uninterrupted reading while having the footnote content visibly available) and lifting them into the text.
"Bigfoot", inspired by a design pattern used by Instapaper at the time, was once a hugely popular "inline footnote pop-up" solution: through progressive enhancement, footnote markers (default markup: an a anchor link and a ol list at the end of the text) are replaced with a clickable UI element (semantically correct: a button) that opens a tooltip-style pop-up containing the footnote text (a aside block created on the fly after clicking, which probably comes with some accessibility limitations).
While effectively abandoned, there is a maintained jQuery-free fork called Littlefoot, which also has received a good amount of a11y-related updates so should at least be somewhat accessible.
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.
PPK inlines sidenotes when authoring the document (by means of a custom <note></note> wrapper), enhances it with some markup required to create a link and then positions the <note> element absolutely.
Continuing in the follow-up post, he then further develops the approach into what essentially resembles the "slide-in UX" seen on some other experiments before. Personally, I find these very hard to use (still haven't properly figured out how to close them again), so maybe this is not the path I would want to go for sidenotes on mobile.
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.