Meeting minutes
There's pools on the roofs in Vienna, too. Matthew?
Agenda Review & Announcements
janina: Standard agenda today.
matatk: Proposed augmentation to idrefs, little reminder.
<matatk> Ref our discussion last week on IDREFs: https://
<matatk> Proposing to discuss in APA WG call, probably the 15th (not sure yet)
janina: This is porposed augmentation that we want our group mind onbefore it becomes a thing. IN ase we have any problems with it bcoming a thing and so on.
matatk: All that's needing to be said is in teh link.
Fredrik: Weird grammar, sorry.
TPAC 2025
janina: Nothing specific.
<JenStrickland> The only thing I have is that the Sustainable Web Interest Group would love to chat with APA.
janina: If you think you want to do a breakout, the deadline for proposing breakouts is looming.
janina: Today is October 1, in three weeks, proposed breakouts are due.
janina: We are T/6 weeks from TPAC.
JenStrickland: The Sustainable Web IG would like to talk with APA.
JenStrickland: I'm co-leading the SWIG. What they're interested in is to best understand how to approach horiyontal review.
JenStrickland: I think APA is the better choice for talking about HzR.
janina: Is the SWIG going to be Kobe-bound?
janina: We'll be happy to talk: coordination needed, though.
matatk: Sounds good.
JenStrickland: I will be more assertive to the point of aggression with my chairs in terms of pushing them to talk to APAWG.
janina: You might want to talk to AGWG aobut something, but not HzR.
JenStrickland: Lots of praise for Janina and Matthew. Well deserved, says Fredrik.
janina; Committing to spruce up her LinkedIn all the while.
New on TR
matatk: I think we can skip this.
Spec review requests
janina: Gremlins detected.
matatk: Some stuff prepared.
2025-09-25: DID Resolution
<matatk> current review request: w3c/
<matatk> longitudinal tracking: w3c/
matatk: WE have longitudinal tracking. *Is that lentitudinal tracking? asks Fredrik, if it's late and all)
matatk: They DID a self review.
matatk: Against the FAST checklist, no less.
matatk: Now that the TAG a11y screener is out, for early stage stuff we should encourage people ot do that.
matatk: For late stage we've got the HTML version of the FAST checklist.
matatk: Comign up, that is.
matatk: We do have some history but it sounds liek 2024.12.04 we suggested Lionel to review but we don't see any results of that.
matatk; I think we'll close this one.
2025-10-16: Screen Orientation
<matatk> current review request: w3c/
<matatk> longitudinal tracking: w3c/
2025-10-18: DAPT
<matatk> current review request: w3c/
<matatk> longitudinal tracking: w3c/
Fredrik: sorry, haven't gotten to it...
<matatk> Following back through these links and minutes, we did want to raise the cross-cutting issue about audio mixing and routing, but were happy last time we reviewed DAPT: https://
2025-10-31: css-color-adjust-1
<matatk> current review request: w3c/
Issue tracking
matatk: Scribe takeover time!
JenStrickland: Lordy, good rest you!
[css-overflow] Line-clamp and screen readers
<matatk> tracking: w3c/
matatk: line clamp and screen readers
… what should happen to clamped content in the axTree?
… currently, I think, it doesn't work like that in other areas
JenStrickland: it's about "fringing" and visual noise on the page. I think the comment here summarizes it well.
matatk: if the point is a preview and it's a long one, you'll be stuck in a preview for a while
<JenStrickland> line-clamp at MDN: https://
PaulG: I think the footgun here for authors is that yes, you can put tooltips, and people often do... there are two ways to use the tooltip - for the description or the name.
… If you have a preview in which everyone is getting it cut off, that's a like experience. The question is: is there a way that is discoverable to AT users to get to the full content.
… The pattern would be for screen reader users: if they get the full content, then they find the tooltip, then they have got the full content twice.
… Are we telling authors: make a tooltip, but take it out of tab order? Seems not good for keyboard users. ARIA hide it? Again creates SNAFUs.
… This works so similarly to overflow, why would we do it differently? As I understand, overflow is going to read all the text.
… I think people will put all the content in there, and the tooltip, and AT users will get the content twice if they engage with the tooltip.
<JenStrickland> +1 to Paul
PaulG: I think this is the cleanest possible situation or it will be confusing to authors.
… So this is the best we can do
JonCohn: Will the screen reader be able to distinguish that this is a tooltip with the full content in it?
PaulG: If I was trying to author this experience for someone with a screen reader and it _did_ limit the text, I would put a description on the item just for screen reader users that said 'use the tooltip to get the full text' as the description will be read. The screen reader is likely to find the full content anyway before the preview.
… Those are also footguns for most authors.
… My guess is there are very few opportunities here to do something that makes sense.
… Having the tooltip for the full text _and_ the preview for the full text is, back to matatk's comment, a problem.
JonCohn: Users won't be aware of this.
PaulG: There is an APG pattern for it.
janina: You have to know about it.
PaulG: It has low support.
https://
PaulG: While the intention is great, the way to carry this out is so limited, we can't expect it to actually work. Therefore you can't use it.
… I think we should let the whole content through, and when the user encounters the tooltip,t hey will at least have all the content, which is better than not being able to access the full content.
janina: Nobody listens to the whole thing - you wouldn't get anything done!
JonCohn: I believe that JAWS by default ignores tooltips, but not sure about other screen readers off the top of my head.
PaulG: When I coach people on how to make a tooltip, I am really pushing for that's a s visual affordance - everything else should be taken care of via aria-describedby etc. attached to the focused element.
… role=tooltip is for visual / future
… It's over-used.
<Fazio> AI overview agrees
<Fazio> Web summary says tooltips are not recognized by AT
matatk: I think I agree it should match overflow. There's pros and cons and notes for the authors. The fact that the role of tooltip isn't supported isn't terrible because the content is associated by name/description.
… I will draft a comment from APA and we can asynchronously collect comments and post it.
Add an ::interest-button pseudo element to interest invokers
tracking: w3c/
matatk: the example is a form and there's an "i" button next to the label. They're proposing to make that the pseudo-button.
… this removes javascript from the interaction.
PaulG: Larger discussion about 'interest' came up again recently. One example was carousel 'tabs'. With tabs, we have a pattern: there's a tablist, tabs, and a tabpanel. Their example doesn't take into account how to apply the role. In CSS there's no way to add it becuase these are all pseudo-elements.
… So their whole interest API is devoid of roles that people know and are using in ARIA. That's a problem. This is going to recreate tooltip in a worse way. Because you have this 'interest thing' which has to be focusable so it's keyboard accessible, and now we're saying that its CSS content is to provide the name and description.
… This is very bad. So I raised it on the call. To say we (accessibility people) don't recommend using CSS content for anything other than presentation.
… The house of cards looks to be collapsing - the demos have feature creep and are not accessible.
matatk: they want to set html attributes dynamically and to do this "correctly" with proper role isn't less complicated than how we do it now without this feature.
janina: we could elevate this to an APA position
PaulG: This isn't the issue that was discussed in CSSWG but it's another one - that one was sent back for rework. Once you lay out how we could point to existing HTML content, this proposal doesn't bring us anything. Happy to help edit comment. Demos needed. Theory not convincing