Daring Fireball Footnotes
Last week, Clagnut’s Richard Rutter commented about John Gruber’s interesting technique for producing footnotes on his Daring Fireball site. One of the most interesting aspects was John’s use of a Unicode hooked arrow character, ↩, to take the reader back to the right place in the text. Very convenient!
Following Richard’s first mention of the technique, John wrote an article about it describing details. I very much like the appearance and usability aspects, so thought I would see how it plays in a few screen readers. I tried with my collection of Freedom Scientific’s Jaws 6.1, IBM Home Page Reader 3.04, and GW Micro’s Window Eyes 5.0. As almost always, we have mixed results.
None of the three tools displayed the Unicode character. Jaws and Window Eyes displayed a box glyph and HPR displayed a question mark. John has his own footnote about this deficiency.
Now, for behavior…
Listenting to the pages read as a stream and trying to hit the links was very difficult. Both the superscript link and the hooked arrow return link are single characters which whiz by too quickly when the screen reader is cranked up fast listening speeds. It was easier to hit the links in HPR, mostly because it is naturally a bit more verbose and announces “superscript.” I had to drop into item by item reading mode to activate the links in Jaws and Window Eyes.
Jaws was the best. It facilitated navigation to the footnote, and return back to the superscripted link. One hears the link being read again after the return, but that is where the anchor exists and should be expected as normal behavior.
HPR was next best. Navigation to the footnote behaves as expected, but return takes one back to the start of the paragraph containing the superscript link. You get to hear more repeated material than you expect. It is almost like HPR associates the anchor position with the paragraph, not the superscript where the anchor is described.
Window Eyes was disappointing. It fails to treat either the footnote link or the return link as on-page links. For either of these, it reloads the page and starts reading from the top.
John coded the anchors for these links using the id attribute, not the name attribute. The technique is perfectly legitimate, looks forward to the day when the name attribute might become deprecated, and his page validates. So, this has given me one more future test case to build, a more complete comparison of behaviors of id attributes vs. name attributes.
I made recordings of the top of John’s page and a round trip through the footnotes for both Jaws and HPR. No recording for Window Eyes since it would be full of long annoying repetitions.
- Daring Fireball’s footnote article
- Daring Fireball’s footnotes excerpt in Jaws 6.1 (111 kb)
- Daring Fireball’s footnotes excerpt in IBM HPR 3.04 (114 kb)
July 23rd, 2005 at 11:43 am
I tried to test this in MacOS X Tiger’s VoiceOver but I cannot for the life of me figure out how to make links within a single page work. When I select footnote link 1, for example, the page itself scrolls down to the footnote but nothing is read. If I select Control-Option-right arrow (the command to read the next thing) it continues right after the link with “In print…” rather than with the text of the footnote. In messing with settings, I finally did make it jump down and read footnotes but clicking on 1 made it read footnote #2! None of the return buttons worked at all. I have found similar problems with skip-nav links which scroll the page but leave the cursor at the top of the page. I cannot figure out how to make a link within a page ALSO move the cursor of what the screen reader is currently looking at.
So, unless someone can shed some light on this, this doesn’t work at all in VoiceOver under MacOS X 10.4.x.
-A
July 28th, 2005 at 8:02 am
Nice one Bob. We’ll have to add that to the list of things for the Accessibility Task Force to take to vendors such as GWMicro. Window Eyes should recognize the id fragment identifier as an in-page link, and if they don’t, it needs to be fixed.
August 3rd, 2005 at 9:08 am
INTERESTING THAT THE REVIEWER TALKS ABOUT LISTENING TO THE PAGE AS A STREAM AND THE DIFFICULTIES THIS CAUSES. THE ONLY PEOPLE i’VE COME ACROSS WHW EVER USE A SCREENREADER IN THIS WAY ARE DEVELOPERS. IT ISN’T IN MY EXPERIENCE HOW vi PEOPLE USE SCREENREADERS. HAPPY TO BE CONTRADICTED BY ANY SCREENREADER USERS BUT IT’S NOT WHAT i’VE SEEN OR WHAT i HAVE TRAINED.
January 5th, 2006 at 11:46 pm
Interesting point. The workshops I’ve gone to stress using the stream. maybe we should test more with those who rely on screenreaders.