This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. 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. 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. Use case: Raymond finds context changes disorienting, so installs a browser add-in (or user style sheet) that attempts to reduce the number of jumps and links he needs to take. Ideally this would move footnotes from a section of their own (or wherever the author chose to put them) to follow the paragraph in which they occur. However, it only wants to do this with notes and perhaps abbreviation expansions, not with other types of links. To do this it would need to be able to identify footnote references as well as the block of associated footnote content. When reading the footnote content, it could automatically stop at the end rather than continuing to read the following notes until Raymond manually stops it. 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. 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. 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. Keep in mind that some users with low vision will need to override the small size of superscript and subscript in order to keep them legible, for example with a user style sheet or by turning off their browser's option to let content override the default font size. However, they will still need to visually distinguish them in some other fashion. If an element such as aside is used for notes, it could also provide a convenient way to let the user agent assign the note reference character, symbol or string (as with the ol element) should the author not want to specify their own.
mass-moved component to LC1
(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.
Bug triage sub-team thinks HTML A11Y TF should track although this is lower priority than other issues.
Mass move to "HTML WG"
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: later Change Description: no spec change Rationale: after reading through the comments it appears there are 2 possible methods to for this to be progressed by the person who raised the bug (or any other interested party) 1. develop an extension spec for a new element <footnote> for example. For information on how to do so refer to: http://www.w3.org/html/wg/wiki/ExtensionHowTo 2. As at least on accessibility API[1] has defined roles for footnote/endnote it is suggested that an alternative route would be to propose ARIA 1.1 add a role="footnote" and/or role="endnote" which if accepted and implemented would mean that the semantics would be exposed to AT when added to existing html elements example: <p role="footnote"> xxx xxxx </p> New ARIA 1.1 features can be proposed via the wai-xtech mailing list [2] [1] http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_role_8idl.html#e37ff81431ee3762a5d41a2cb909108d [2] http://lists.w3.org/Archives/Public/wai-xtech/