Expand support for isElementVisible (VisuallyHidden)#77191
Open
Expand support for isElementVisible (VisuallyHidden)#77191
isElementVisible (VisuallyHidden)#77191Conversation
mirka
commented
Apr 9, 2026
| "@wordpress/rich-text": "file:../rich-text", | ||
| "@wordpress/style-engine": "file:../style-engine", | ||
| "@wordpress/token-list": "file:../token-list", | ||
| "@wordpress/ui": "file:../ui", |
Member
Author
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.
Comment on lines
+18
to
+19
| // @ts-expect-error - Data attribute that should stay hardcoded and not overridden by consumers. | ||
| 'data-visually-hidden': '', |
Member
Author
There was a problem hiding this comment.
Adding an arbitrary data attribute wouldn't be a type error in normal JSX, so this is a limitation of this prop object structure. I think it's simplest to expect-error here.
8 tasks
github-actions
bot
added
[Package] Components
|
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: +4 B (0%) Total Size: 7.74 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 1327b70. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24195415788
|
ciampo
reviewed
Apr 10, 2026
| { | ||
| className: styles[ 'visually-hidden' ], | ||
| // @ts-expect-error - Data attribute that should stay hardcoded and not overridden by consumers. | ||
| 'data-visually-hidden': '', |
Contributor
There was a problem hiding this comment.
Question (no strong opinions): should we prefix the attribute with some wp or wp-ui specific string?
| // Check for <VisuallyHidden> component. | ||
| if ( element.classList.contains( 'components-visually-hidden' ) ) { | ||
| // Check for <VisuallyHidden> components. | ||
| if ( element.getAttribute( 'data-visually-hidden' ) ) { |
Contributor
There was a problem hiding this comment.
This check may be buggy, the attribute has a value of "", which causes the check to fail.
For extra clarity and correctness, I feel like it should be changed to
Suggested change
| if ( element.getAttribute( 'data-visually-hidden' ) ) { | |
| if ( element.hasAttribute( 'data-visually-hidden' ) ) { |
|
|
||
| describe( 'dom', () => { | ||
| describe( 'isElementVisible', () => { | ||
| it( 'returns false for @wordpress/components VisuallyHidden', () => { |
Contributor
There was a problem hiding this comment.
Related to the previous comment, these tests may be currently passing for the wrong reason — ie. the getAttribute check instead of hasAttribute.
The tests may actually be passing because of the getBoundingClientRect check a few lines after the attribute check.
We should probably consider mocking getBoundingClientRect which should also surface the getAttribute bug:
it( 'returns false for @wordpress/components VisuallyHidden', () => {
render(
<WCVisuallyHidden data-testid="components-visually-hidden">
Hidden
</WCVisuallyHidden>
);
const element = screen.getByTestId( 'components-visually-hidden' );
element.getBoundingClientRect = jest.fn( () => ( {
x: 0, y: 0, width: 100, height: 20,
top: 0, right: 100, bottom: 20, left: 0,
} ) );
expect( isElementVisible( element ) ).toBe( false );
} );either for the indivisual tests, or for the whole suite
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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