Xiaocheng: Want to have Matthew drive this review, as I was involved in the spec process, and I’m obviously very positive. I proposed a lot of ideas. My question is, there was a concern raised by Mozilla, but I think it is wrong, and I’m trying to confirm this.

Lola: Matthew, are you okay driving this? Do you need another reviewer?

Matthew: APA is looking at this at the same time, we are working on suggestions for the A11y considerations section, and should be done on that fairly soon. Not sure if we commented on this before. Will keep you all updated. Core thing that it does is really good for accessibility. Seems like a nice feature. There were a couple of concerns about the accessibility considerations section. We are working on some suggestions, more on this soon.

Xiaocheng: I’d like Matthew to drive this review.

Matthew: As said last week, APA is looking at it, we want things specifically to put in the a11y considerations section. No additional concerns or updates since last week, we’ll be wrapping it up from an APA perspective before next week. Will mention it in Slack if anything comes up, no active updates otherwise.

Hadley: More broadly than a11y, no other feedback?

Matthew: Trying to do that from TAG perspective, but looking forward from additional insights from CSS experts.

Hadley: Want to clarify the status regarding TAG activity. You are part-way through that?

Matthew: Yes.

Matthew: I had mentioned that APA was providing feedback on accessibiliyt considerations. I wasn't concerned about most of it. Overall it seems like a good trend, moving stuff out of javascript into CSS, more declarative etc. So, no pure CSS concerns. But from APA's view, it crates a trap for developers, because it removes boilerplate code but you stil have to do the js if you're doing this with custom elements, you have to do the keyboard handling and ARIA etc. So how much does it save developers? It's probably a net positive, but smaller than it might have been.

APA worry that people will think "we just do this and it's accessible", but it isn't. APA will be emphasising that.

So this is moving in a positive direction, but we do need to make developers aware it's not a "get out of javascript free" card.

I don't know if Xiaocheng has extra thoughts? He was involved in writing the spec. It's due on the 30 January, which is the last day of their face to face. The next one is April.

Hadley: so the TAG view on this is that it's fine, assuming the accessibility issues get sorted with APA?

Matthew: yes. We need to set those expectations with developers. Guidance, not normative.

Matthew: Could not think of any architectural no-nos. There is a11y stuff that we are working with them separately, we are help them to revamp their a11y considerations section. Somebody raised the question if this could worsen the situation for screen magnifier users. Xiaocheng and I don’t think so.

… While you end up with a couple of harmful side effects (two-dimensional scrolling in the web page and the virtual computer screen), which is why … layouts are great. Other thing is, if a dialog pops up somewhere on the screen, you may not see it. If it’s a native dialog, focus usually moves. But things like tooltips etc. may not have this behavior. Might only be a problem if you have zoomed-in significantly. However, I don’t think it’s worse than the status quo, with the benefit of not having to write the JavaScript glue code. Xiaocheng agrees. Don’t think this is a reason to say no, and there are quite some reasons to say yes. Agree that you would need to have some communication between the page and the AT (?) which we may not want to have. We don’t think this makes it any worse, and we should be positive about this.

Xiaocheng: Agree.

Matthew: Think I know what we’re doing with this, but the discussion isn’t in the TAG bot. Two of us were in agreement that this is a step forward. APA thinks this doesn’t make it any worse, and it does some really good stuff as well. There’s an a11y section coming from APA that is in the works. Propose a closing comment along those lines. Correct, Xiaocheng?

Xiaocheng: Yes.

Lola: If TAG bot is dropping comments, let us know in Slack.

(Skipped.)

Matthew: we were pretty happy with this. APA are working with them separately on accessibility considerations. Jeffrey said it would've been helpful to do an early design review of this, but it's a late review. I agree, and I think we can just post Jeffrey's comment.

Hadley: We could say that we can be much more helpful at a later stage. Add to private brainstorming?

Matthew: Done. Do we want satisfied or satisfied with concerns?

Hadley: Expressing our concerns in the closing comments should cover it enough.

Matthew: Drafting. Post it or have reviewed?

Hadley: Happy to let you do it.

Matthew: There’s a reply about one of Xiaocheng’s questions pointing us at Web Platform Tests.

… From the private thread, we ended up with a private comment. From the breakout minutes, we talked about adding that earlier reviews would be helpful. Looks like no one picked this up. Will take care of this, put it in Slack, and then post. We might have to wait until Xiaocheng is available.

Sarven: If they're offering to provide more data, could we get that in any way? Difference between the to engines?

Matthew: Two threads, Xiaocheng raised a question and got a specific answer, and Jeffrey talked about the general timing of reviews before things go to CR. Will draft something and ping Xiaocheng.

Matthew to write comment

Matthew: Agreed on this one that we are happy, need to write the comment.

Luke: Did we have a detailed look into visibility? Seems counter-intuitive to what I as a developer expect.

Matthew: Just searched the minutes… in the review request, it introduced position area and properties. It doesn’t come up later. What I suggest is to leave a comment in the private brainstorming thread so Xiaocheng can have a look.

(Luke to post that comment.)

Luke: It's a review for a thing that's Baseline "newly available" so already shipped (Anchor Positioning Level 1). I have some concerns with position-visibility property. I can't evaluate implementation, even in spec unsure it address usecases. I will write draft comment that summerises my concerns. position-visibility was added later and also very buggy so there may still be time to change. The idea of position-visibility allows you to address popover sticky header issues.

Xiaocheng: Is the sticky header issue fixable? is it a spec or implementation bug, or something fundamental with anchor positioning?

Luke: I think it's a spec bug and not just an implementation bug. I think intersecion observer v2 has this concept of visibility, and I think we have the mechanics for it. it's a matter of specying nad implementing to meet those mechanics. I htink it's been designed wit ha specific use case in mind, where you ahsomething anchored but not directly next to the anchor, and the anchor goes off screen and you want to get rid of the info box about the thing. Whereas I imagine it's where you have stuff where they are next to or close to each other, and one gets obscured and you wnat to hide the other.

Hadley: Xiaochengh how do you want to review Luke's comment?

Xiaocheng: I'll look at his comment.

Lola: luke do you have anything to add?

Luke: I am writing draft comment now regarding position-visiility which I think doesn't necessarily meet the requirement. I might write a comment to mention the comments and then check with them how it works before shipping it.

Lola: this pattern is happening more often recently. This maybe because we have a long backlog.

Luke: yes, this is from Dec 2025, but this is not massive long wait to justify the shipping in the browser.

Lola: we can have a look in the closing comment as I can't remember from the top of my head.

Lola: Oh, there is a comment from them pending from 2023.

Luke: Oh, so I don't include this in my comments, so I will double check and modify my comment.

Lola: Jeffrey did mention it in the gh comments, so you can find it.

Luke: Have a draft comment. Thoughts?

Matthew: Had a look at it, but it was a while ago. Need to read it again. How does, say, a popup reappear? Line by line or all at once?

Luke: All at once.

Matthew: Would it still be open if it’s out of the viewport, semantically?

Luke: Semantically, it’s open, but it doesn’t render. Not sure if it’s hidden from the accessibility tree.

Xiaocheng: Via visibility, maybe made. this choice because of AT.

Matthew: If display: none removes things completely, what does visibility: hidden do?

Luke: It’s actually visibility: forced-hidden.

Matthew: Agree we need to get some clarification on this.

Lola: visibility: hidden removes it from the a11y tree.

Luke: Makes sense, I will note this down and post to the private brainstorming.

Matthew: Both Luke and Xiaocheng have raised good questions. Think the last comment in the private thread has a very specific and focused technical question which we should pass on to the proponents. Luke is expressing some concerns and created a demo. I think it would be a good idea to pass that demo as well. Plan is to draft a comment, want to leave it to Luke to pick up the demo and Xiaocheng’s concern.

Christian to ask Luke.

(Skipped.)

Luke: Posted a draft comment last week. Matthew +1'd.