Expand support for isElementVisible (VisuallyHidden)#77191
Conversation
| "@wordpress/rich-text": "file:../rich-text", | ||
| "@wordpress/style-engine": "file:../style-engine", | ||
| "@wordpress/token-list": "file:../token-list", | ||
| "@wordpress/ui": "file:../ui", |
There was a problem hiding this comment.
This is technically still a dev dependency, but I went ahead and added it as a normal dependency since we'll be actually using the UI components in production soon enough.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -3 B (0%) Total Size: 7.75 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 1558ba2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24754615673
|
ciampo
left a comment
There was a problem hiding this comment.
LGTM 🚀
Pre-approving since remaining feedback is minor and won't need a further round of review
| // @ts-expect-error - Data attribute that should stay hardcoded and not overridden by consumers. | ||
| 'data-visually-hidden': '', |
There was a problem hiding this comment.
any consumer that spreads a data-visually-hidden (including data-visually-hidden={ undefined }) will silently blank out the attribute and defeat the detection.
Should we move these lines after restProps ?
| <WCVisuallyHidden data-testid="components-visually-hidden"> | ||
| Hidden | ||
| </WCVisuallyHidden> | ||
| ); | ||
| const element = screen.getByTestId( 'components-visually-hidden' ); |
There was a problem hiding this comment.
Nit: avoid previous classname naming scheme?
| <WCVisuallyHidden data-testid="components-visually-hidden"> | |
| Hidden | |
| </WCVisuallyHidden> | |
| ); | |
| const element = screen.getByTestId( 'components-visually-hidden' ); | |
| <WCVisuallyHidden data-testid="wc-visually-hidden"> | |
| Hidden | |
| </WCVisuallyHidden> | |
| ); | |
| const element = screen.getByTestId( 'wc-visually-hidden' ); |
| { className: styles[ 'visually-hidden' ] }, | ||
| { | ||
| className: styles[ 'visually-hidden' ], | ||
| // @ts-expect-error - Data attribute that should stay hardcoded and not overridden by consumers. |
There was a problem hiding this comment.
Nit: more accurate message about the TS error
| // @ts-expect-error - Data attribute that should stay hardcoded and not overridden by consumers. | |
| // @ts-expect-error Arbitrary data-* attributes aren't indexable on the typed div props. Kept hardcoded so consumers can't change or remove it. |
What?
Part of #76135
Expands support for the
isElementVisible()utility function in@wordpress/block-editorso any component can opt in by adding adata-visually-hiddenattribute on itself.Why?
isElementVisible()function does its best to detect element visibility, but there's a limit to that becauseVisuallyHidden-like components are intentionally designed to evade these kinds of checks so they can remain in the accessibility tree. So there used to be some special handling for theVisuallyHiddencomponent in@wordpress/components, based on its CSS class name.There are several scalability issues with this approach, because arbitrary components cannot willingly add themselves to this special handling, and also not all components have identifiable CSS classes.
I considered a few possible approaches (including trying to specifically detect a
VisuallyHidden-like pattern with more CSS-based checks), and I concluded that the best way was to change the approach from a CSS class name to a data attribute.Testing Instructions
Unit tests pass.
Use of AI Tools
To scaffold unit tests