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

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.

https://wordpress.org/gutenberg/

Other

10.48k stars 4.18k forks source link

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

Open afercia opened 5 years ago

afercia commented 5 years ago

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:

https://github.com/WordPress/gutenberg/blob/68367b4b9c869900eca07b9a9b3750ee52915c46/packages/editor/src/components/rich-text/tinymce.js#L356-L364

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:

screenshot 2018-12-02 at 17 00 32

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

screenshot 2018-12-02 at 16 32 54

ellatrix commented 5 years ago

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

afercia commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

But they are text areas in a table cell?

What can we change?

ellatrix commented 5 years ago

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

afercia commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/WordPress/gutenberg/pull/4074#issuecomment-376571587

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 commented 5 years ago

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 commented 2 years ago

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. 👍