Repository navigation
[css-view-transition-1] visibility: hidden analogy is misleading, elements remain keyboard-focusable and accessible #12629
Description
Hi,
The current css-view-transitions-1 draft at point 4.2. View Transition Painting Order, says:
When a Document’s active view transition’s phase is "animating", the boxes generated by any element in that Document with captured in a view transition and its element contents, except transition root pseudo-element’s inclusive descendants, are not painted (as if they had
visibility: hidden) and do not respond to hit-testing (as if they hadpointer-events: none).
Note: Elements participating in a transition need to skip painting in their DOM location because their image is painted in the corresponding
::view-transition-new()pseudo-element instead. Similarly, hit-testing is skipped because the element’s DOM location does not correspond to where its contents are rendered. However, there is no change in how these elements are accessed by assistive technologies or the accessibility tree.
The issue is that the use of visibility: hidden in the following sentence:
are not painted (as if they had
visibility: hidden) and do not respond to hit-testing (as if they hadpointer-events: none).
is problematic with this sentence:
there is no change in how these elements are accessed by assistive technologies or the accessibility tree.
because visibility: hidden don't just make the element invisible and not-interactive, it also remove it from the accessibility tree.
Also, visibility: hidden doesn’t reflect how Chrome and Firefox currently preserve element focusability and interactivity, while opacity: 0 combined with pointer-events: none matches their behavior.
Related issue:
- [css-view-transitions-1] Add a11y text to specify how VT works with it #9365
- [css-view-transitions-2] Figure out a way to make hit-testing work on live (new) elements during a view transition #10930
Testing links:
Activity
[-][css-view-transition-1] Clarifications regarding interactivity and accesibility[/-][+][css-view-transition-1] `visibility: hidden` analogy conflicts with accessibility behavior[/+][-][css-view-transition-1] `visibility: hidden` analogy conflicts with accessibility behavior[/-][+][css-view-transition-1] `visibility: hidden` analogy is misleading, elements remain keyboard-focusable and accessible[/+]sb3nder commentedon Sep 1, 2025
visibility: visibledisabled)readonly)aria-hidden="true"inertopacity: 0visibility: hidden,display: nonefantasai commentedon Sep 11, 2025
This should go on the agenda by TPAC at the latest, I think.
css-meeting-bot commentedon Jan 21, 2026
The CSS Working Group just discussed
[css-view-transition-1] `visibility: hidden` analogy is misleading, elements remain keyboard-focusable and accessible, and agreed to the following:RESOLVED: change to "as opacity:0"The full IRC log of that discussion
<TabAtkins> vmpstr: this is skirting the line of editorial<TabAtkins> vmpstr: in the spec we say that elements that are eparticipating in a view transition don't paint where they're ac Tually positioned
<TabAtkins> vmpstr: in parens, "as if they're visibility:hidden".
<TabAtkins> vmpstr: person filing the issue said hidden comes with other implications, like keyboard-focus. suggested we rephrase to "as opacity:0". fine with that
<flackr> +1
<bramus> +1
<emilio> sgtm
<TabAtkins> I think this is indeed editorial, and go for it
<TabAtkins> astearns: k, so proposed resolution: change to "as opacity:0"
<TabAtkins> RESOLVED: change to "as opacity:0"