Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-view-transitions-1] Add a11y text to specify how VT works with it #9365

Closed
vmpstr opened this issue Sep 15, 2023 · 2 comments
Closed

[css-view-transitions-1] Add a11y text to specify how VT works with it #9365

vmpstr opened this issue Sep 15, 2023 · 2 comments
Labels
css-view-transitions-1 View Transitions; Bugs only Needs Edits

Comments

@vmpstr
Copy link
Member

vmpstr commented Sep 15, 2023

We've had an early review for a11y with recommendations to ignore the generated view transition pseudo tree for the purposes of a11y. We should capture that in the spec

We also need to discuss the text in view transition spec that currently 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 are invisible.

I don't think we want it to say invisible, since 1. it's contents are visible via the pseudo elements and 2., invisible elements means, among other things, that the elements

are also not rendered to speech (except when speak is always [CSS-SPEECH-1])

We'd like those to be available to a11y since otherwise the content would not be available to speech in any way

@vmpstr vmpstr added the css-view-transitions-1 View Transitions; Bugs only label Sep 15, 2023
@khushalsagar
Copy link
Member

FWIW, this text was changed in #9028.

Our goal is to say that elements being snapshotted for a transition don't paint (because we steal their snapshot and show them in the pseudo-elements) and are not interactive. The latter because the hit-test would resolve on the element even though its not painting at that location.

The earlier text lined up better with this intent:

The [=new element=] and its contents
(the flat tree descendants of the element, including both text and elements, or the replaced content of a replaced element),
except the |transition|'s [=ViewTransition/transition root pseudo-element=]'s [=tree/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) until |new| exists.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-view-transitions-1] Add a11y text to specify how VT works with it, and agreed to the following:

  • RESOLVED: Add accessibility non-treatment agreed up on at TPAC to the spec, stating the view transition pseudos are presentational and have no special accessibility needs
The full IRC log of that discussion <emeyer> vmpstr: We talked at TPAC about how the view tree is not exposed to the a11y tree in any way
<emeyer> …We would like to make changes to the spec so we have things written down
<emeyer> …During the spec edits, we refactored to say the underlying element is invisible, but that’s not the correct term
<emeyer> …We would need a different term that means it’s visually hidden but exposed to a11y
<khush> q+
<astearns> ack khush
<emeyer> khush: There is spec text that was in before we changed it, which said “invisible boxes”
<emeyer> …I think that’s closer to what we want
<emeyer> …It did miss talking about pseudo-elements being skipped by screen readers and so on
<emeyer> PaulG: One of the reason I didn’t go back to APA because this seemed presentational
<emeyer> …Presentational content is not lifted into the AX tree
<emeyer> …Unless these pseudo-elements can carry additional information the way ::before and ::after can, I don’t see a reason to push for this
<emeyer> vmpstr: Can you clarify? The proposal is that we’ll skip the AX tree
<emeyer> PaulG: Ah, okay, I thought the proposal was to augment. We’re aligned, thank you
<emeyer> …I think presentational will mean something to a11y folks and they’rll start to understand this has no mapped role
<emeyer> …I think presentational is the term that will make the most sense
<astearns> ack fantasai
<emeyer> fantasai: Seems like we all agree on the behavior
<emeyer> …Is the question how we describe that in the spec, or what’s the open question?
<emeyer> vmpstr: It’s just about the spec text
<emeyer> astearns: We could resolve to update the spec to take the feedback we received at TPAC
<emeyer> PaulG: Not sure if you need to tag for horizontal review, but I would take it to APA to make sure they don’t have a problem
<emeyer> astearns: So, we add text saying the pseudos are not special and don’t need to be treated differently
<fantasai> Something like "The view transition pseudo tree is only used for visual rendering, and is not exposed to other media or to the accessibility tree" ?
<emeyer> …Any objections?
<emeyer> (silence)
<emeyer> RESOLVED: Add accessibility non-treatment agreed up on at TPAC to the spec, stating the view transition pseudos are presentational and have no special accessibility needs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-view-transitions-1 View Transitions; Bugs only Needs Edits
Projects
None yet
Development

No branches or pull requests

3 participants