Table block: the RichText within the table cells shouldn't have role=textbox and aria-multiline=true

[afercia]

For all the usages of the RichText component within the various blocks, Gutenberg uses a role=textbox and an aria-multiline=true attribute to make the editable field perceived by assistive technologies as equivalent of a <textarea> element.

The only exception used to be the Table block: a specific exception was coded a while ago:

gutenberg/packages/editor/src/components/rich-text/tinymce.js

Lines 356 to 364 in 68367b4

	/*
	* The role=textbox and aria-multiline=true must always be used together
	* as TinyMCE always behaves like a sort of textarea where text wraps in
	* multiple lines. Only the table block editable element is excluded.
	*/
	if ( tagName !== 'table' ) {
	ariaProps.role = 'textbox';
	ariaProps[ 'aria-multiline' ] = true;
	}

The rationale behind this exception is:

• all the other blocks editable areas need to be communicated to assistive technologies like a textarea (some doubts were expressed about the List block)
• instead, the Table block needs to keep the table native semantic, and the table cells need to be communicated as editable cells

This worked but the Table block and RichText have seen some refactoring over time and now seems it doesn't work any longer:

As a consequence, screen readers announce a textarea within a table cell, which is potentially confusing for users:

[ellatrix]

Current behaviour seems fine to me? What do you want to change? You are in a text area in a table cell.

[afercia]

I'd like the cells editable areas to not be communicated as texareas. That means: removing role=textbox and aria-multiline=true when RichText is inside the table.

That worked with the previous implementation of the Table block because the passed tag name was table. Now, at the very least the exception

if ( tagName !== 'table' ) { ...

doesn't make sense because tagName is the default div. Checking for tagName wouldn't work. The only option I can see would be checking the className but that's a bit meh... there's the need to pass something from the Table block to RichText to make it aware it's within a Table block and not render role=textbox aria-multiline=true.

[ellatrix]

Before the whole table was an editable field, so that made sense to me.

Currently each cell is a editable field, not the whole table, so it is the same as placing a text area in each cell. They are no different from any other editable field, e.g. a caption. Both are text boxes and multiline.

[afercia]

From a semantic perspective and considering how screen readers announce the current semantic, it's not the same thing.

I'm just asking to restore the previous semantics, when the table cells were announced as editable table cells. Instead, now screen readers will announce a textarea within a table cell, which is potentially greatly confusing for users.

This was the only reason why that exception was introduced. Can we please restore a similar behavior? 🙂

[ellatrix]

But they are text areas in a table cell?

What can we change?

[ellatrix]

Atm, we cannot have <td contenteditable> as there are wrapping elements which would be invalid HTML.

[afercia]

They're not textareas 🙂 They're <div> elements with a contenteditabe attribute.

• role="textbox" aria-multiline="true" give them the semantic of a textarea
• if we remove role="textbox" aria-multiline="true" they will be just div elements, and only the parent cell will be announced

[ellatrix]

:)

I'll rephrase my question...

But they are semantically text areas?

if we remove role="textbox" aria-multiline="true" they will be just div elements, and only the parent cell will be announced

That seems wrong? Why is a table cell any different from any other rich text instance? The cell is announced, so everything seems fine to me?

[afercia]

A table element is very different from all the other elements, as there are relationships between the cells that are announced by screen readers. Quoting from the original PR #4074 (comment)

we should not set the role="textbox" on blocks that are completely different from inputs or textareas:

• list: loses its native semantics: number of items etc. are no longer announced
• table: same, the number of rows and columns are no longer announced, as well as the current position in the table

Later, we changed our mind about the List block and kept the exception only for the Table.

[ellatrix]

So if we remove the attributes, rows and columns and current position is announced, and that's currently not the case?

we should not set the role="textbox" on blocks that are completely different from inputs or textareas

The current implementation is the same as putting a text area element inside a table cell, so I don't really get what's different about it.

[alexstine]

Is this one still relevant?

Body cell text  edit  multi line  
blank
Body cell text  edit  multi line  column 2  
Body cell text  edit  multi line  row 2  
Body cell text  edit  multi line  column 1  

Seems like the table info is still read. Not sure if that would be the case for Voiceover or not, but works well enough for NVDA. 👍

[Mamaduka]

@afercia, can we close this issue?

[afercia]

@afercia, can we close this issue?

This issue is from 2018, long time has passed since then. I see that on Octobre 2020 #26582 added some aria-label attributes to the RichText components used inside the table cella. That is the reason why they are now announced with some meaningful labeling.

gutenberg/packages/block-library/src/table/edit.js

Lines 78 to 82 in ed4c2d3

	const cellAriaLabel = {
	head: __( 'Header cell text' ),
	body: __( 'Body cell text' ),
	foot: __( 'Footer cell text' ),
	};

so that for example the editable div element inside a normal table cell is announced as Body cell text. Testing with Safari and VoiceOver:

it announces Body cell text, edit text. Noting that without the aria-labels added in #26582 the cells would have been announced as edit text, thus loosing any reference to the table semantics, which was the whole point of this issue.

While the added labeling helps I would argue the role is still wrong but I'm fine with closing this issue as there's now at least some feedback provided to users that they are inside a table cell.