-
Notifications
You must be signed in to change notification settings - Fork 711
[css-view-transitions-1] Add a11y text to specify how VT works with it #9365
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
Comments
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 CSS Working Group just discussed
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 |
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:
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
We'd like those to be available to a11y since otherwise the content would not be available to speech in any way
The text was updated successfully, but these errors were encountered: