Observed behavior
Table of contents entries are implemented with <button> elements instead of <a> elements. They do not point to the corresponding headings in the document. A user navigating from link to link with a screen reader will not find the table of contents content. A keyboard user who activates a table of contents entry does not see their focus moved to the corresponding section.
Expected behavior
Table of contents entries must be <a href="#heading-id"> links pointing to the corresponding headings in the document. Activating an entry must move focus to the target heading, whether the user is in reading or editing mode.
Steps to reproduce
- Open a Docs document containing a table of contents
- Navigate with a screen reader in link navigation mode (K key in NVDA)
- Observe that table of contents entries are absent from the list of links
- Navigate with keyboard and activate a table of contents entry
- Observe that focus is not moved to the corresponding heading in the document
Possible solution
<!-- Before -->
<button type="button" aria-label="Introduction" aria-selecred="false">Introduction</button>
<!-- After -->
<a href="#heading-introduction">Introduction</a>
Each heading in the document must also receive a unique identifier serving as a target:
<h2 id="heading-introduction" class="bn-inline-content">Introduction</h2>
Additional context / Screenshots
The <button> semantic is reserved for actions (opening a modal, submitting a form, etc.). Navigation to a section of a document is a navigation action: it falls under the link category. This distinction is fundamental for users of assistive technologies who rely on the nature of elements to build their navigation strategy.
RGAA criteria
[Critère 6.1 : Chaque lien est-il explicite ?
Impact
A blind user navigating with a screen reader in link navigation mode cannot find table of contents entries: they are invisible in this navigation mode. A user navigating with keyboard in a long document cannot use the table of contents to move efficiently, their focus remaining at its initial position after activating an entry.
Priority
P0
Observed behavior
Table of contents entries are implemented with
<button>elements instead of<a>elements. They do not point to the corresponding headings in the document. A user navigating from link to link with a screen reader will not find the table of contents content. A keyboard user who activates a table of contents entry does not see their focus moved to the corresponding section.Expected behavior
Table of contents entries must be
<a href="#heading-id">links pointing to the corresponding headings in the document. Activating an entry must move focus to the target heading, whether the user is in reading or editing mode.Steps to reproduce
Possible solution
Each heading in the document must also receive a unique identifier serving as a target:
Additional context / Screenshots
The
<button>semantic is reserved for actions (opening a modal, submitting a form, etc.). Navigation to a section of a document is a navigation action: it falls under the link category. This distinction is fundamental for users of assistive technologies who rely on the nature of elements to build their navigation strategy.RGAA criteria
[Critère 6.1 : Chaque lien est-il explicite ?
Impact
A blind user navigating with a screen reader in link navigation mode cannot find table of contents entries: they are invisible in this navigation mode. A user navigating with keyboard in a long document cannot use the table of contents to move efficiently, their focus remaining at its initial position after activating an entry.
Priority
P0