Accessibility Recipes/Footnotes

From DPWiki
Jump to navigation Jump to search

Sadly, our default footnote markup as generated by Guiguts is something of an accessibility disaster. But there are ways of fixing it.

What to do and how?

There isn't just one right way. First we'll show a way that improves matters greatly while not altering the look or layout of the file one jot. Secondly, if that's too much effort, we'll see how some improvement can be made just with a simple search and replace. Further ways, such as have been suggested in the forums, are welcome!

The Looks-the-same Method

The ideas are to turn the list of footnotes at the end into a real list instead of a sequence of <div>s; to put the return link at the end of the footnote text in the code (since that's where you'd want to use it) but use CSS to position it in the usual place; and to put some title attributes on the links to help the user know where they are going.

The CSS and HTML

First, what it looks like. In the CSS (bold bits are what's different from usual; the rest, keep what you normally like or what Guiguts puts):

.footnotes  {border: dashed 1px; margin-top:1em; clear:both;}
.footnotes ol { margin-left:0; margin-right:0;
        list-style-type:none; }
.footnote   {margin-left: 10%; margin-right: 10%; width:80%;
        font-size: 0.9em;
.footnote .label  {position: absolute; 
        left:-3em; top:0;
        text-align: left; }
.fnanchor   {vertical-align:baseline;
        position:relative; bottom:0.4em;
        font-size: .8em; }

What this does is makes an ordered list with suppressed numbering and indentation; makes each footnote into a "container" by giving it width (for IE) and relative position (for normal browsers); then the footnote label is absolutely positioned within this container to place it at the top left as usual. Now the HTML for the anchor is very simple:

<a name="Anchor-1" id="Anchor-1"></a><a title="Go to footnote 1" href="#Footnote-1" class="fnanchor">1</a>

Nothing unusual there, except we've added a title attribute saying where the link goes and made the name and id a bit more normal. Finally, here's the HTML for the list of footnotes:

<div class="footnotes" style="margin-top:3em;">

<h3 class="center">FOOTNOTES:</h3>

<ol> <li class="footnote"><p><a name="Footnote-1" id="Footnote-1"></a>This poem is here quoted, by permission, from Mr. MacKaye’s volume, <cite>The Present Hour</cite>. Published by The Macmillan Company, New York.</p> <a title="Return to text" href="#Anchor-1" class="label">[1]</a> </li>

<li class="footnote"><p><a name="Footnote-2" id="Footnote-2"></a>Reprinted by permission of Funk & Wagnalls Company.</p> <a title="Return to text" href="#Anchor-2" class="label">[2]</a> </li> </ol>


So each footnote is a list item; the content of the footnote can be a <p> as here, or several, or can easily contain poetry, lists or whatever else. All those things are valid inside a <li>. Also, the return link comes after the text of the footnote, and also has a title attribute.

Regexes to get this

Regexes have been tested in Guiguts and SubEthaEdit on Mac. Ask in Regular expression clinic if you have any problems.

  1. Search class="fnanchor">\[([^\]]+)\] Replace class="fnanchor" title="Go to footnote $1.">[$1]
    This adds the title attribute to all the anchors.
  2. Search href="#FNanchor Replace title="Return to text." href="#FNanchor
    This adds the title attribute to all the return links.
  3. Search <div class="footnote">([\s\S]+?)(<a title="Return[\s\S]+?</a>)([\s\S]+?)</div>\n\n Replace <li class="footnote">$1$3\n$2 </li>\n\n
    This moves the return link to the end of the footnote, although the CSS will still position it in the usual spot. You might need to hit "Replace All" more than once.
  4. Put in your CSS in the header. Add the <ol> before the first footnote, and the </ol> after the last. Everything should be working now!
  5. Search (<a title="Return to text."[^>]+>)<span class="label">\[([^\]]+)\]</span></a> Replace <span class="label">[$1$2</a>]</span>.
    Takes the brackets out of the return links, as a token gesture towards avoiding duplicate link text. Also fixes the IE5-Mac footnote bug.
  6. Search FNanchor Replace Anchor
    Gives the anchors friendlier names, since some users might actually hear them.
  7. ONLY IF you've just one series of footnotes: Search Footnote_([^_]+)_[^_]+?" replace Footnote-$1" and Anchor_([^_]+)_[^_]+?" replace Anchor-$1"
    Simplifies the Anchor_1_1, Footnote_1_1 stuff to just Anchor-1, Footnote-1. This will sound better if read out.

For utmost perfection maybe give the classes more concise names. But that's it!

The Lazy Partial Version

If you don't feel like rearranging your code that much, merely adding the title attributes to the links and replacing FNanchor with Anchor will help a little bit. Just follow the above regexes missing out steps 3 and 4. Or if you detest regexes, the following ordinary searches are almost as good (will say just "Go to footnote" rather than "Go to footnote 1"; if the link gets read out it will contain "underscore" a couple of times):

  1. Search class="fnanchor"> Replace class="fnanchor" title="Go to footnote.">
  2. Search href="#FNanchor Replace title="Return to text." href="#FNanchor
  3. Search: FNanchor Replace Anchor



As you can imagine, footnotes aren't very common on the web, so the W3C don't say anything specific about them. But they do talk about using markup in a meaningful way, and about making it clear where links are taking you.

  • WCAG 1, Checkpoint 13.1 Clearly identify the target of each link. (Priority 2)
    • Link text should indicate the nature of the link target.
    • If more than one link on a page shares the same link text, all those links should point to the same resource.
    • If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.
  • WCAG 1, Checkpoint 3.6 Mark up lists and list items properly. (Priority 2)
  • Draft WCAG 2, Success criteria 2.4.4, 2.4.8 The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A); The purpose of each link can be identified from the link text. (Level AAA)
  • Draft WCAG 2, Success criterion 1.3.1 Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies. (Level A) Instructions provided for understanding and operating content do not rely on shape, size, visual location, or orientation of components. (Level A)
    • Using ol, ul and dl for lists.

So clearly the ideal would be for our footnote link to actually say "Go to footnote 1", but that would be very obtrusive visually stuck in the middle of the passage of text. The above suggested methods are compromises.

Who benefits?

The major benefit is for blind users: those who can see the layout can probably work out what's going on with footnotes, but using a screenreader our default footnote markup is extremely confusing, as demonstrated below. Also, our default markup puts the return link before the text of the footnote—so the person has to listen through the footnote, and then do some backskipping to get to the return link (if they even realised that's what it was for).

The other less serious issue is that some users, such as those with motor disabilities, like to move around the document by calling up a list of all the links on the page. If two look alike (the [1] going to a link, and [1] back again) that's not too helpful. Although, one might argue that since an eBook is often riddled with single-number links from the ToC and Index such users might quickly decide to navigate by headings instead. Sophisticated browsers might show the title attribute in the list of links, which could help.

Finally, the tooltip when hovering over the link may make the footnote and return link more understandable to any readers who haven't seen an eBook before.

Screenreader Footnote Hell!

I tried listening to a project of my own (done using the usual Guiguts-generated footnote markup) in FireVox. I heard:

... occupying the place which has been assigned to him in creation. Internal link: One.

Hmm, I wonder where that goes? Perhaps it's a footnote. Then I followed the link, and immediately heard

Internal link: One

Hang on, did I press the repeat key instead of the follow-link key?  Let's try again.

Internal link: One

Oh heck.  I'm confused now.  Another go?  Eventually I give up and just let it continue speaking.  I hear

But in order to employ analogy with effect more is needful than....

Goes on like this for a few sentences, until

...and the exposition of analogies.  Internal link: Two.

Shall I follow it this time?  I try, and get

Internal link: Two. The difficulty of constructing a definition....

Just for kicks, I go back and try not following the link.  I get

Christ made it his business to speak in....

See the problem?  Anyone know which of the bits I quoted were in the main body of the book, and which were footnotes?  In between where I heard "One" and where I heard "Two", was that me reading the passage or was that me reading down the list of footnotes at the end?  It depends on whether, in my confusion at the first link, I followed it an odd or even number of times!

So, is it better with the markup suggested above? A bit. After I hear "Internal link: One." I can press the "query" key, and hear

Title: Go to footnote 1. This is an internal link to section footnote 1.

When I follow the link, it tells me that I've landed in a list, and which item I am on:

Ordered list with one-hundred four items. One. But in order to employ analogy....

I listen through the footnote, and then

... construction and the exposition of analogies. Internal link: One.

This is the return link, right when I want it. If that's not clear to me, I hit "query" and get

Title: Return to text. This is an internal link to section anchor 1.

And supposing I don't follow the return link, but just keep listening, I get

2. Christ made it his business....

The 2 is telling me that I'm now on the second item of that 104-item list.


The first method given has no drawbacks at all, unless you vehemently hate tooltips, because in every other respect the page looks and behaves exactly as it did with Guiguts-generated markup. Turn off the CSS, and it still looks good (probably better than the GG version would). So the main drawback is the effort of implementing it.

The Lazy version again has no drawbacks unless you have a tooltip allergy.


  • Most online accessibility checkers will tell you if you have identical links going to different places. But they are easily fooled by, say, altering the brackets—which won't help screenreader users because it won't normally read out the brackets.
    • Ocawa is one to try. Set it to Priority 2 or 3.

Further Reading