Skip to content

Table headers are not associated with data cells #2825

Open

Description

@Ovgodd

What’s broken?

This issue was identified during the Docs accessibility audit on a page containing table-related content.

Audited page:
https://docs.numerique.gouv.fr/docs/0d998bef-1b69-47ce-bd18-83d4d849c734/

In BlockNote tables, users can define row and column headers, and the generated markup uses <th> elements.

However, these headers are not explicitly associated with their related data cells.

There is currently no clear header relationship exposed through:

  • scope="col"
  • scope="row"
  • id / headers relationships for complex tables

Because of this, screen readers may not reliably announce which header applies to each table cell.

This can make table content difficult or impossible to understand for blind users navigating with assistive technologies.

What did you expect to happen?

Table headers should be correctly associated with their related cells.

For simple tables, BlockNote should expose header relationships using scope.

Example:

<table>
  <thead>
    <tr>
      <th scope="col">Name</th>
      <th scope="col">Role</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Alice</th>
      <td>Designer</td>
    </tr>
  </tbody>
</table>

Steps to reproduce

  1. Insert a table
  2. Define one or more row or column headers.
  3. Inspect the generated table in the DOM.
  4. Notice that the table uses <th> elements, but there is no explicit relationship between headers and data cells:
    • no scope="col" on column headers;
    • no scope="row" on row headers;
    • no id / headers relationship for more complex tables.

BlockNote version

0.51.4

Activity

  1. added
    needs-triageIssue has not yet been reviewed or classified by maintainers.
    on Jun 4, 2026
  2. added and removed
    needs-triageIssue has not yet been reviewed or classified by maintainers.
    on Jun 15, 2026
  3. matthewlipski commented on Oct 22, 2026

    @matthewlipski
    Collaborator

    Hi, this is being addressed in #3215, though while looking into this issue I didn't find that adding scope/header made much of a difference to screen reader support and not having those attributes did not flag issues in an axe-core scan. Do you have any specific examples of e.g. incorrect screen reader callouts that come from this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions