- From: sb3nder via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 13:02:02 +0000
- To: public-css-archive@w3.org
sb3nder has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transition-1] Clarifications regarding interactivity and accesibility == Hi, The current css-view-transitions-1 draft at point [4.2. View Transition Painting Order](https://drafts.csswg.org/css-view-transitions-1/#view-transition-rendering), 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 had `pointer-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. I want to focus on these 2 part: >are not painted (as if they had `visibility: hidden`) and do not respond to hit-testing (as if they had `pointer-events: none`). >there is no change in how these elements are accessed by assistive technologies or the accessibility tree. --- ## Definitions First, I wasn’t familiar with the term *hit-testing*, so I looked up this [definition from the W3C wiki](https://www.w3.org/wiki/Hit_Testing), which says: >In computer graphics programming, hit-testing (hit detection, picking, or pick correlation) is the process of determining whether a user-controlled cursor (such as a mouse cursor or touch-point on a touch-screen interface) intersects a given shape, line, or curve drawn on the screen. This may be done for movements of the pointer or the underlying shape, or restricted to user-initiated selection, such as a mouse-click. If I understand correctly, hit-testing refers only to pointer inputs, and does not include non-pointer input devices such as keyboards, game controllers, text cursor caret browsing, or screen readers. --- The `visibility: hidden` definition from the [css-display-3 spec](https://drafts.csswg.org/css-display-3/#visibility) says: >Any boxes generated by the element are invisible. Descendants of the element can, however, be visible if they have visibility: visible. >Invisible boxes are not rendered (as if they were fully transparent), cannot be interacted with (and behave as if they had pointer-events: none), are removed from navigation (similar to display: none), and are also not rendered to speech (except when speak is always [CSS-SPEECH-1]). However, as with display: contents, their semantic role as a container is not affected, to ensure that any visible descendants are properly interpreted. And [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/visibility) adds: >The element box is invisible (not drawn), but still affects layout as normal. Descendants of the element will be visible if they have `visibility` set to `visible`. The element cannot receive focus (such as when navigating through tab indexes). >Using a `visibility` value of `hidden` on an element will remove it from the accessibility tree. This will cause the element and all its descendant elements to no longer be announced by screen reading technology. --- ## Issue My concern 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 had `pointer-events: none`). is incompatible with the following sentence: >there is no change in how these elements are accessed by assistive technologies or the accessibility tree. and it's also incompatible with the current implementation in both Chrome and Firefox. Perhaps `opacity: 0` would be a better analogy, as it aligns more closely with current implementations. If specifications and implementations move toward using `visibility: hidden` during view transitions, how will screen readers detect when a page is in the middle of a transition? Is there any flag or mechanism that screen readers can use to identify a 'transition in progress'? --- ## Additional informations [MDN](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API/Using#an_aside_on_snapshots) say this about snapshot interactivity: >The snapshot of the old UI state is a static image, so that the user can't interact with it as it animates "out". >The snapshot of the new UI state is an interactive DOM region, so that the user can start to interact with the new content as it animates "in". --- CSS Working Group recently discussed [`[css-view-transitions-2] Figure out a way to make hit-testing work on live (new) elements during a view transition`](https://github.com/w3c/csswg-drafts/issues/10930#issuecomment-3200568288). Here are some highlights related to this issue: >... <ntim> kbabbitt: I'm curious about a11y implication. if an element is clickable, it should also be keyboard accessible. How does it work with tab order? <ntim> flackr: they're not focusable <ntim> emilio: per spec, they're not focusable <ntim> emilio/noamr: per-spec, considered invisible <ntim> e.g. not focusable or hit testable <ntim> flackr: with the current spec, you would lose focus (changing focus styles) and lose tab order of things, maybe this didn't matter for whole document VT, but might be important for scoped VT to accomplish animation <ntim> kbabbitt: I'm wondering, given that, does it make sense for both old and new to be hit-testable for tab order? <ntim> flackr: old state stops existing completely <ntim> kbabbitt: This is about making new state hit testable? whereas before it would do nothing ... <ntim> noamr: We need to deal with keyboard navigation before resolving on this <ntim> bramus: aren't these separate? <ntim> noamr: if you make a button clickable during the VT, but it goes out of tab order, then it creates a weird inconsistency during the transition --- Testing links: - https://codepen.io/sb3nder/pen/QwjmmZy - https://mdn.github.io/dom-examples/view-transitions/mpa/index.html - https://mdn.github.io/dom-examples/view-transitions/spa --- Related issue: - https://github.com/w3c/csswg-drafts/issues/10930 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12629 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 13:02:02 UTC