W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

[Bug 13666] Improve handling of footnotes and endnotes

From: <bugzilla@jessica.w3.org>
Date: Sat, 06 Aug 2011 11:59:36 +0000
To: public-html-a11y@w3.org
Message-Id: <E1QpfXU-0002vJ-6d@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13666

Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bhawkeslewis@googlemail.com

--- Comment #2 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-06 11:59:35 UTC ---
(In reply to comment #0)
> The HTML5 spec does not have a dedicated mechanism for marking up footnotes and
> endnotes, instead providing example of three different mechanisms that could be
> used. I've not been able to find the rationale for this, including the decision
> to drop the footnote link type, but as well as being a problem for the
> publishing industry it is detrimental for accessibility.

You can find Hixie's rationale at:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014485.html

The "footnote" link type was never added, so it was never dropped. But anyone
is free to register it.

> My preference would be to use an element equivalent to aside, or aside with a
> type modifier, which would give the user agent and therefore the user more
> flexibility in how the reference and content are presented to the user, as well
> as to the interaction used to view or hide the content.

I agree this would be best, assuming further development and implementation of
various proposed CSS features for reformatting elements as footnotes.

> Use case: Roderick uses a screen reader. As a document is being read to him and
> a footnote reference is encountered, he would prefer to hear a tone or simple
> "Footnote", rather than something like "superscript fifty-three endsuperscript"
> or worse, merely "fifty-three". In this case he does not need to know the
> number; hearing that there's a footnote he could simply press a keyboard
> command to jump to the footnote content. He would certainly not want the screen
> reader to assume that anything in superscripts is a footnote reference, or else
> things like <abbr>M<sup>lle</sup></abbr> Gwendoline</span> would be interpreted
> incorrectly.

Some platform accessibility APIs do have semantics for notes. IAccessible2
includes footnote and endnote roles.

Users might want different behavior for (say) pullquotes and footnotes, so it
would be good to have a way to distinguish the two. <aside> doesn't really
deliver here.

> Note that the convention of putting footnote references in hard-coded brackets
> is not appropriate for documents that are attempting to replicate the look and
> feel of print. Neither is the spec's recommendation of putting notes in the
> aside element.

Why not?

Have a look at footnotes section in the CSS Generated Content for Paged Media
Module draft:

http://www.w3.org/TR/css3-gcpm/#footnotes

> If links are still used as footnote references, the text should recommend and
> the examples should show the link pointing to an element that encloses the
> entire footnote content, rather than just to a link at its beginning.

I agree. The CSS draft assumes the fragment contains the footnote rather than
just marking its start.

> Authors should be able to mark up footnote references to indicate whether the
> recommended presentation is as footnotes or endnotes, for user agents that want
> to take advantage of this either when printing or when emulating a printed
> page.

Assuming it's not critical to distinguish between footnotes and endnotes in
terms of the accessibility API representation, this can be handled by "class"
plus CSS.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Saturday, 6 August 2011 11:59:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:43 GMT