Finish resolving accessibility issues with Table Block

[joedolson]

Is your feature request related to a problem? Please describe.

Problem: Cannot create a table with row header cells; can create a table with empty header cells; tables not differentiated between presentational and data; captions use the wrong semantics.

Issues:

• It shouldn't be an option to leave header cells empty, or adding content should be prompted
• Tables without any header cells should be marked as role="presentation"
• The figure/figcaption implementation is a strange choice, given that there is a standard caption element (see comment on 15554)

See also #15283 for prior work towards making the table block accessible.

Describe the solution you'd like

• Should be able to add a header column
• If no headers added, table should be presumed to be presentational
• Captions should use 'caption' element
• If header cells are present and empty, user should be prompted to complete them or the cells should be reverted to .

[NicktheGeek]

Hi all,

I just wanted to chime in on this issue to add some background and hopefully clarity.

There have been a few attempts to make accessible tables in gutenberg and I appreciate the effort. I think the reason this hasn't landed quite right is because the nature of this can be confusing.

There are a few details required to make a table accessible

• A valid caption. This allows screen readers to identify multiple tables on a page. It is also good for sighted users to get a high level understanding of the table contents at a glance. Tables are often long and data dense, so the caption explains this in a few words without needing to take in the whole table.
• Valid HTML markup. This is mostly resolved with the current implantation but it's very important that this is expressed clearly as changes should conform to valid HTML standard to avoid regression
• Clear and valid cell headings. This is the <th> markup. It needs to be easy for users to define a cell as a "heading" cell. Conversely they need to be able to define a cell as "not a heading" cell otherwise known as a "data" cell. These are used in screen readers to label a cell. I'll provide an example of what this means below.
• Clear and valid scope. This is applied to a <th> like <th scope="col"> and <th scope="row">. It's also possible to have row and column group scopes but since there isn't a merge option right now, that isn't necessary. The scope makes it clear what the heading applies to. A heading cell with a scope row is all we can currently do and it is applied to the thead cells automatically and exclusively. However, tables are very often two axis labels, with the left or right column being used to label the row cells.

Here is an example table. It's in markdown and there are limitations there, so I will not say this is fully accessible.

Date	Ammonia	Nitrites	Nitrates	pH	CO2
May 1	0	0	5	7.3	18
May 2	0.1	0	8	7.3	20
May 3	0	0.1	12	7.4	16

If this were accessible it would have a <caption>. As it stands the top row should render with <thead> and each cell would be <th scope="col">. That is how things currently work in the block editor. This would help a screen reader with reading the cell data during navigation of the table, but not completely. At this point, with no <th scope="row"> a reader on the Nitrates column in the second <tbody> row would hear something like "Nitrates 8."

Instead, the first cell of each row in <tbody> should be encoded with <th scope="row">. Then if a user navigated to the cell I described before they might hear "Nitrates May 2 8." The exact phrasing will vary from app to app and based on verbosity settings, but you can see how that is much more helpful.

So the expected HTML would be

<table>
<caption>Aquarium Data</caption>
<thead>
  <tr>
    <th scope="col">Date</th>
    <th scope="col">Ammonia</th>
    <th scope="col">Nitrites</th>
    <th scope="col">Nitrates</th>
    <th scope="col">pH</th>
    <th scope="col">CO2</th>
  </tr>
</thead>
<tbody>
  <tr>
    <th scope="row">May 1</td>
    <td>0</td>
    <td>0</td>
    <td>5</td>
    <td>7.3</td>
    <td>18</td>
  </tr>
  <tr>
  	<th scope="row">May 2</th>
    <td>0.1</td>
    <td>0</td>
    <td>8</td>
    <td>7.3</td>
    <td>20</td>
  </tr>
  <tr>
  	<th scope="row">May 3</th>
    <td>0</td>
    <td>0.1</td>
    <td>12</td>
    <td>7.4</td>
    <td>16</td>
  </tr>
</tbody>
</table>

There are a lot more complexities with tables. It should be possible to merge cells, build inner tables, set scope to colgroup and rowgroup, define IDs for each cell and row, then set aria-label and aria-labeledby in order to make complex tables, but I think at this point the goal should be to make flat tables fully accessible and let people use an HTML block for complex tables as they really need a lot of special consideration to make them correctly accessible.

I hope seeing the completed HTML and hearing the reasoning behind this request makes it more clear.

I'm also willing to work on a PR for these changes.

• Fix caption HTML
• Add per cell controls to set cell heading and scope

[talldan]

Just to provide some feedback, as I've worked a bit on the table block in the past, and it's important that in the process of addressing these points other regressions aren't introduced.

The figure/figcaption implementation is a strange choice, given that there is a standard caption element

@joedolson <caption> was the first thing attempted, but my memory is that the combination of a contenteditable caption and screenreaders didn't mix particularly well. If I remember correctly, the element could be edited, but Voiceover wouldn't read the caption when navigating to the table. A second challenge is that a table caption element has to be in the DOM before a tbody according to the HTML spec, which results in its tab order being incorrect if it appears visually after the table.

The next part is that to solve a separate accessibility issue, the table had to be wrapped with another element to make it scrollable (#16324). A div could have been used, but given the issues with getting caption working, using a figure for the scroll container and a figcaption for the caption were used.

Happy to see a caption explored if those issues can be solved, but as part of changing this the figure should also be changed to something else (a div?) as per the spec:
https://html.spec.whatwg.org/multipage/tables.html#the-caption-element

Clear and valid scope.

@NicktheGeek This would be great. I think the challenge here is that most users consider this block like a spreadsheet, and don't understand these semantics and won't know what a 'scope' is or why it's important. The worst result would be that this feature is misunderstood by users and so not used. The best result is that adding row headers feels like a natural part of building a table and the scope is added as a transparent part of that process.

[NicktheGeek]

@talldan thanks for the feedback.

I think the challenge here is that most users consider this block like a spreadsheet, and don't understand these semantics and won't know what a 'scope' is or why it's important.

I agree most users don't understand this. Most users don't understand they need to add clear and meaningful alt tags. They either don't add them, or say something like "image of a red apple." Worse they think that's the place to put all their keywords.

One of the reasons I ended up finding this issue and previous issues was a direct result of a series I'm writing on building accessible content. I wrote up the section on tables then a colleague reviewed it. He said that I wasn't focused too much on theory and needed to give usage examples like other sections. He was right so I created an example form, which I used in my comment, and tried to build this correctly in the block editor and realized it isn't possible.

If people don't know what to do, we solve it by educating them. That's what my series is all about, teaching people how to make accessible content.

If people can't do it right, we fix the tools.

If the worst case is that users don't know what to do and leave the current functionality, then there is no negative in providing this. The real worst case is that they just randomly mark cells as headers and really mess up their markup/accessibility. We solve that with education too. There are so many tools that people can misuse and abuse in ignorance. They exist for people to do it right, but that won't stop people from doing it wrong. I've got 2 chain saws and I fell trees that have died/are dying in the fall then cut them up so I can split them and stack the wood to dry for burning the following season. Chainsaws can be misused and the consequence can be life threatening. I wear lots of safety gear but the most important thing to keep me from the ER is education.

I like that the heading and scope get set automatically for the <thead>. It's simple and addresses how users will most likely set up a table.

I like the suggestion that during the save process, any cell that is a <th> with no inner content should be rendered as a <td>. This gets tricky for incomplete forms, so the edit view should retain <th>.

We just need a simple, and intuitive way to control cell heading and scope via the editor so that users who do know what they are doing have more control to do it right while retaining the current process of assigning it automatically to the heading row and ensuring that the front end output doesn't contain empty <th> cells.

I think this is something we can do.

[joedolson]

So, another thing to observe about the table captions: it should be different depending on whether the table is a data table or a presentational table. A data table is expected to have a caption element; but a layout table must not.

I can see the argument about the positioning of the caption, and having the editable region match the visible position or having the tab order not match the visual order. However, for identifying accessible data tables, the caption element is very much the right choice, so this might require some kind of compromise. I think we should prioritize the user experience for visitors to the site over administrators, however, as that is the broader reach for almost all sites.

Using figcaption and figure, the table may not be available to screen readers using their 'Tables' browse feature, as this feature commonly depends on the caption element. (Note: it does work in NVDA/Firefox) The figcaption/figure combination is also less widely supported by AT compared to the standard HTML element. (As engineered in Gutenberg 8.6.1, this does not work in NVDA/Firefox.)

In order to give the site visitor the best experience, using a caption element is needed. If this means that the back-end has an out of order element, that may be what we need to do.

Note: for screen readers, the caption is read first regardless of which side it's visually displayed on, so at least for screen reader users in the editor, at least in some ways, the read order & the edit order will match. For screen readers, the caption is more equivalent to a label for a form field or the aria-label to a landmark region, and is used to identify the table. When doing a line-by-line reading, the caption will appear at the end of the table if it is positioned with caption-side: bottom.

Also note that testing with Voiceover should be considered the exception, and not the rule; Voiceover is the most unusual screen reader, and in general the goal should be to ensure function in Windows screen readers, then try and work out why Voiceover is doing something differently. Obviously there can be exceptions to this.

[LukaszJaro]

I played around with a custom accessible block table that addressed these issues very simply:

https://github.com/stmarytx/cgb-a11y-table/tree/master

Using the toggle adds the necessary scope to the column or row.

Here are my thoughts working in the real world with content editors, they do want to make accessible tables but it should be simpler to do.

Most use cases just need a table with header cells in the top row only

Many forgot to enable the header section and wonder why their headings are not bolded or styled like other tables which do use a header section with th.

By default 'header section' should be toggled true. I'm not aware of any content editor that is using the table for presentation but if someone decides to turn headers off then the table can be automatically labelled as presentation.

The scope should added automatically when adding header or row section even if its a easy to understand table since it does no harm.

Also when inserting a table a mini wizard can be presented that shows various layouts that can be selected, this would help users achieve accessibility as well:

• Table with header cells in the top row only (default)
• Table with header cells in the first column only
• Table with header cells in the top row and first column

As for more complicated tables, I discourage them and either find ways where you can break the complicated table down into smaller and simple tables or find a alternative ways of presenting the data.

[hidde]

This is an older issue, but came in to echo @joedolson's point that a caption in a table is essential, as it names a table and tables without names are harder to find for end users, especially users with screenreaders.

I wonder if this has been explored: a caption field in the block settings that doesn't display in the editor, but does show up as a caption in the outputted HTML? This way editors would have to jump into the settings to edit it, which isnt' ideal, but at least it would stop the current situation where authors are prevented from creating accessible markup. Thanks for considering!

[annezazu]

@richtabor wanted to bring your attention to this current issue as I see you're working on some recent designs to improve aspects of the table block right now: #49275 I wonder if there are ways to incorporate the concerns here into what might be worked on.

[richtabor]

So, another thing to observe about the table captions: it should be different depending on whether the table is a data table or a presentational table. A data table is expected to have a caption element; but a layout table must not.

Is the simplest solution to render the existing figcaption value within the <table> element, as a <caption> as well?

[joedolson]

That's part of the solution; it also needs to be conditional: the caption should only be available when table headers are present, either row or column headers, so that those semantics aren't added on tables that are only presentational.