I use footnotes on this blog, but have often found them annoying to implement, write, and deal with, so I found Jake Archibald’s post on footnotes an interesting take on the matter:
If reproduced as-is, footnotes on the web are even worse than their printed counterparts. In print, the footnotes are usually at the bottom of the current page, so they’re a quick glance away, and you can use a finger to mark your place in the main text while you’re off on your side-quest. Whereas on this beautiful pageless web of ours, you have to scroll all the way down to the end of the article. You can try flinging right to the bottom of the document, but if there’s a sizeable footer or comments section, you’ll overshoot the footnotes. And of course, after all of this, you have to scroll back to where you were, which is easier said than done.
Jake suggests myriad ways to deal with this problem, most of which I’d already implemented, but none of them solve the root problems:
- Footnotes are less accessible, because they’re often set smaller than body text.
- On the printed page, footnotes can exist in the footer of any page. This makes them unobtrusive to read, since the size of a page is restricted by the physical limitations of books. Your eyes don’t have to travel far. On the web, no such luck: a webpage can be a mile long, so placing footers at the end of the document can turn footnotes into a very un-fun game.
The bigger problem in my mind is #2, and I’ve been contemplating solutions to this for some time.
On the web, I’ve often thought the best solution is using something similar to <aside> or <section role="notes"> in the way Jake describes. Ideally, each “footnote” would directly follow the paragraph it pertains to.
On desktop, these footnotes could be displayed in the margins of the page. (It’s called marginalia for a reason.) The smaller type can stay, mostly as a way to semantically highlight the insignificance of the footnote itself, which almost certainly exists for the author’s sake and not the reader’s. This works really well in Klim Type Co’s essays and case studies. (Unfortunately, Klim’s solution doesn’t scale down to mobile.)
I dislike the popup solution, which presents the user which a choice and annoys me personally as a reader. Popups are also annoying to build.
The problem with using <aside> or <section role=“notes”> is that these solutions are not part of any agreed-upon footnote spec. It’s scope creep if you’re building in most CMSs today, including (and probably especially) WordPress. They also don’t render as footnotes in RSS feeds, so your content will be presented differently there than it would be on a website. (One could replace marginalia with normal footnotes for RSS feeds, but again, scope creep.)
For now, one way around it is to use JavaScript to fetch the footnotes and display them inline as marginalia beside the text. I’ve never built this out, but I can imagine a few potential accessibility problems (in addition to the accessibility issues already present for footnotes).
The best solution, outside of abandoning footnotes altogether, is an HTML spec for footnotes that removes the need for each developer to suggest their own implementation. Whatever the spec is, it could incorporate a best-practices approach that allows for CSS styling to transform footnotes into marginalia, something similar to an <aside>, or even a popup. It would also, theoretically, solve accessibility problems that developers create with their own implementations.
For now, a better approach is probably to replace each footnote with a <section role=“note”>, which is an idea I hadn’t considered, but quite like. Thanks Jake!