Size Change: +2 B (0%)

Total Size: 1.33 MB

_{compressed-size-action}

Flaky tests detected in 93317de.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3957213090
📝 Reported issues:

• [Flaky Test] should insert media, convert to blocks, and undo in one step #36123 in specs/editor/blocks/classic.test.js

@vcanales Thanks for the PR. How should I test this? Which blocks should we use to determine a pass or fail? So far, I am not noticing anything broken but would like exact testing steps.

Thanks.

@vcanales thanks for your PR. I'm not sure it would fully solve the issue though.

In #42158 I tried to explain this is a two-fold issue: wrong role passed by useBlockProps and usage of useBlockProps, which is sometimes used on a wrapper element and sometimes used on the RichText component. I think the change in this PR would fix the symptom rather than the actual problem.

To quickly recap:

• The RichText component has a default role="textbox" prop that can be overridden.
• useBlockProps has a role="document" prop.
• Some blocks do have a wrapper element (e.g. Pullquote, etc.), some don't (e.g. Paragraph, Heading, etc.).
• Sometimes, the props from useBlockProps are passed directly to the RichText component, for example in the Paragraph block. As such, the contenteditable element of the Paragraph block has a role="document"
• Sometimes, the props from useBlockProps are passed to the block wrapper instead, for example in the Pullquote block. As such, the wrapper has a role="document' while the contenteditable element has the default role="textbox".

Basically, the presence of the wrapper element and the usage of useBlockProps are greatly inconsistent across blocks. This inconsistency has a deep impact on assistive technologies and affects also other aria attributes and labelling.

To be fair, the current situation is very far from ideal.

I'm not necessarily against this change, as it makes sure an editable 'field' is always exposed to assistive technologies as a textbox. That would solve only one part of the issue though. Also, please notice some tests are failing because they use role="document" as selector.

@alexstine I think this should be tested with JAWS, as the role="document" was meant to address some issues with old JAWS versions. See the pretty long discussion on #29526 and the feedback from Glen Gordon (JAWS software architect) there.

I'd greatly appreciate some help to revive the discussion on #42158 so that it can get some higher priority!

Closing in favor of other efforts. I am thinking about how to modify useBlockProps.

@alexstine I would appreciate a link to the PR that has taken precedence over this one.

@vcanales #53364