Summary
Identifying notes and placing them at logical breaks in the text minimizes their impact on the reading of the primary text.
Techniques
- Identify footnotes using the
doc-footnote
role. [[WCAG-1.3.1]] - Group footnotes or endnotes at the end of a section or work in lists. [[WCAG-1.3.1]]
- Link note references to their notes. [[WCAG-1.3.1]]
- Backlink notes at the end of a section or work to their references. [[WCAG-1.3.1]]
Examples
Frequently Asked Questions
- Should I use the
doc-endnote
role? -
No. Use of the
doc-endnote
role is now deprecated due to a technical incompatibility with the core ARIA role module. ARIA does not allow roles from a module to satisfy the requirements of core roles, so althoughdoc-endnote
behaves like a list item, it technically does not fulfill the requirement that lists have list item children. That makes it invalid in both HTML list elements and as a child of the ARIAlist
role.While AT uses should not experience any problems if you have already used the role, it is best to avoid it moving forward to avoid errors in your content.
The role is also generally redundant. If a section of notes is identified using the
doc-endnotes
role, users and assistive technologies will understand the list within the section contains the endnotes.
Explanation
Footnotes and endnotes have proven an impediment to the reading experience because they interrupt the narrative flow. When footnotes are placed immediately following the paragraph that references them, users had to manually navigate past them each time, as they are typically indistinguishable from text content. Even endnotes, grouped at the end of the section, require the user to jump past them.
The HTML structural elements, together with the role
attribute, provide a means of
alleviating this problem, by clearly marking individual footnotes and endnotes, and sections of them. Not
only does this allow accessible user agents to ignore the notes except when followed from their
referents, but it allows any user agent to handle them more intelligently (e.g., as pop-ups).
Notes that are grouped at the end of a section should be grouped using doc-endnotes
role
(see Example 2). Lists allow users to move through them more effectively
(e.g., each list item number will typically correspond sequentially to the contained note number,
and users should have the ability to jump through more than one list item at a time when there are
many notes).
Notes in Tables
If notes occur in a table, avoid placing them in a tfoot
element, as it is intended for
summaries of the columns. Footnotes can follow the table or can be grouped together with the table inside
a figure
. See the Tables section for an example.
Note References
Note references must be tagged using the HTML a
element to ensure users do not
have to visually locate the corresponding note.
The sup
element may be used to superscript note references, but it adds extra verbosity
(assistive technologies will announce the text is superscripted in addition to being linked).
The CSS vertical-align
property can be set to superscript the a
elements without the additional voicing (see Example 3).
Note
Until there is greater support for announcing the doc-footnote
role, the
sup
element provides some context for the note references. As support for the
role increases, however, the use of explicit superscripting will become redundant. At that
time, preference should be given to CSS formatting.
Back Referencing
Although not specifically required to be accessible, it is good practice to backlink groups of notes to their referent locations in the text (see Example 4). If a user is surveying the notes, backlinks will allow them to quickly find the text the note refers to.
Ensure that the link text for each back reference clearly identifies where the link goes. Avoid using the same text over and over, like "Go to reference". When users of assistive technologies access the list of links on the page, the context of each link is lost.
Related Links
- DPUB-ARIA —
doc-footnote
- DPUB-ARIA —
doc-endnotes