18:00:58 RRSAgent has joined #aria 18:01:02 logging to https://www.w3.org/2026/01/22-aria-irc 18:01:02 giacomo-petri has joined #aria 18:01:02 RRSAgent, make logs Public 18:01:03 Meeting: ARIA WG 18:01:11 Agendabot, find agenda 18:01:11 jamesn, OK. This may take a minute... 18:01:12 agenda: https://www.w3.org/events/meetings/690d057f-db6d-4169-b13f-68d7f1336b59/20260122T130000/ 18:01:12 clear agenda 18:01:12 agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-01-15+repo:w3c/aria&type=Issues 18:01:12 agenda+ -> New Issue Triage https://tinyurl.com/yfnpf9wm 18:01:15 agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y 18:01:17 agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates 18:01:20 agenda+ Webkit landed ARIA notifty and Gecko is implementing! \o/ 18:01:23 agenda+ -> Should :target-current pseudo class also imply aria-current=true on an active scroll marker? https://github.com/w3c/aria/issues/2710 18:01:26 agenda+ -> aria-actions: handling focus when actions are synthetically triggered https://github.com/w3c/aria/issues/2691 18:01:52 scott has joined #aria 18:02:11 Siri has joined #aria 18:02:18 katez has joined #aria 18:02:26 present+ 18:02:34 present+ 18:02:35 present+ 18:02:36 present+ 18:02:40 present+ 18:02:46 dgrogan has joined #aria 18:03:00 aardrian has joined #aria 18:03:02 scribe: spectranaut 18:03:03 sarah has joined #aria 18:03:05 present+ 18:03:07 present+ 18:03:08 present+ 18:03:26 filippo-zorzi has joined #aria 18:03:32 zakim, next item 18:03:32 agendum 1 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-01-15+repo:w3c/aria&type=Issues -- taken up [from agendabot] 18:03:32 I can't comment on that because it doesn't look like a github issue to me. 18:03:32 present+ 18:04:12 https://github.com/w3c/aria/issues/2720 18:04:20 Francis_Storr has joined #aria 18:04:23 present+ 18:04:28 present+ 18:04:35 keithamus: I had an old PR, I updated it, also it's not on my fork, please review 18:04:37 present+ 18:04:39 pkra has joined #aria 18:04:43 jamesn: is it implemented yet? 18:04:51 present+ 18:05:01 keithamus: have implemented in firefox, not implemented in chrome 18:05:11 jamesn: needs reviews 18:05:18 cyns has joined #aria 18:05:20 keithamus: scott reviewed the prior PR 18:05:31 keithamus: updated in light of scotts commentary 18:05:51 scott: I assigned it myself covertly 18:05:55 CurtBellew has joined #aria 18:05:58 Rahim: add me 18:06:08 present+ 18:06:12 clay: I'll review 18:06:27 pkra: me too 18:06:43 https://github.com/w3c/aria/pull/2717 18:06:50 james: mappings for popover hint 18:07:15 keithamus: implemented and chrome, soon shipping in gecko, need a good review -- review is blocking! 18:07:45 scott: me 18:07:50 s/me/I'll review/ 18:08:22 keithamus: I need reviews from the non-engine side, I'm doing what chrome is doing, not sure its right. I want to know what people want from tooltips and these types of patterns 18:08:29 sarah: I will review 18:08:40 aardrian: I'll review too 18:08:53 jamesn: would be good to have someone from webkit 18:09:06 jcraig: fine you can put me 18:09:14 zakim, next item 18:09:14 agendum 2 -- -> New Issue Triage https://tinyurl.com/yfnpf9wm -- taken up [from agendabot] 18:09:14 I can't comment on that because it doesn't look like a github issue to me. 18:09:43 https://github.com/w3c/html-aam/issues/596 18:09:51 scott: rahim or I will take this 18:09:56 present+ 18:10:01 q+ 18:10:09 scott: going through PRs that haven't been merged, this is an outstanding request from rahim 18:10:27 scott: embed is similar to iframe 18:10:45 scott: use it to present graphics and an entire webpages other content. it works the same as iframe for naming 18:10:59 scott: doesn't need assing 18:11:15 https://github.com/w3c/aria/issues/2715 18:11:58 pkra: I don't remember, assign it to me 18:12:25 https://github.com/w3c/aria/issues/2709 18:13:42 jamesn: ok, so, would anyone like to investigate this? first stage is to work out whether this is supported across many platforms, accessibility APIs and maybe AT. Does this need expanding accessibility APIs? 18:14:11 jcraig: do we have anyone on the microsoft side that knows anything about excel? 18:14:15 jcraig: I can ask about numbers 18:14:49 spectranaut_: I'll look into the libreoffice side 18:15:11 jcraig: maybe reaching out to ben for the microsoft side....? 18:15:21 sarah: I can reach out to excel folks 18:16:08 sarah: my team works with office online... but maybe they know who works with native 18:16:16 jcraig: we want to know what is support on platforms specifically 18:16:27 jcraig: because we know it is not supported on the web 18:16:40 jamesn: I'll add agenda so we can bring it back 18:17:21 https://github.com/w3c/aria/issues/2708 18:17:53 jamesn: there is a document, using ARIA, which is maintained by steve, its not within our working group. If you have ideas, share it in the issue, otherwise editors will make a decision 18:18:35 Daniel: we are trying to get steve's input too 18:18:36 https://github.com/w3c/svg-aam/issues/40 18:18:54 jamesn: we talked about this in editors, the decision was to match reality of implementations 18:19:05 cyns: you can assign it to me 18:19:26 pkra: this a feature of svg 2 18:19:40 https://github.com/w3c/css-aam/issues/16 18:19:51 jamesn: did we already talk about this.... 18:19:58 jamesn: keithamus found the tests 18:20:13 jamesn: are there results of the tests...? that would be handy for this 18:20:58 pkra: there is an accname side of this. it isn't really mentioned in accname. it just talks about css content. the implementations do take it into account. 18:21:26 jcraig: css defines what the css content is, so it might not need an edit. the accname spec should point to the css spec, and the is definitive enough to write tests for it 18:21:35 pkra: i didn't see a lot of css content alternative tests 18:21:56 pkra: if you read accname you might miss it, could use a note 18:22:21 jamesn: accname references lots of spec 18:22:22 q+ 18:22:35 (I missed something james said) 18:22:44 Rahim: can we add a label.... 18:22:52 jamesn: the issue is in CSS AAM 18:23:37 jamesn: personally, I think things like htisi should be in CSS AAM 18:23:51 jamesn: implementation details like this that impact accessibility are notes 18:23:58 s/notes/noted/ 18:24:32 q+ 18:24:46 pkra: I filled this for three reasons, one is that it is talking about aam side of things, two mentions CSS-AAM specifically, third is the accname part mentions speech 18:25:10 pkra: we should do something from our end is import to clarify what is going on when you use these things 18:25:14 ack Rahim 18:26:11 aardrian: one nugget, this issue appears to be looking at three different documents. developers try to read and follow the accname spec. last week I had a convo about css carousels -- sometimes in the accname it is implied not clear 18:26:30 aardrian: the expectation is that accname covers any input that feeds into accname 18:26:44 pkra: so it covers css content but not alternatives 18:26:46 aardrian: right 18:27:01 pkra: it references css-2 which doesn't have alternatives 18:27:21 spectranaut_: I think we should agenda this 18:27:37 Matt_King has joined #aria 18:27:43 zakim, next item 18:27:43 I see a speaker queue remaining and respectfully decline to close this agendum, spectranaut_ 18:27:49 ack aardrian 18:27:50 zakim, next item 18:27:50 agendum 3 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot] 18:27:50 I can't comment on that because it doesn't look like a github issue to me. 18:27:52 present+ 18:28:16 zakim, close this item 18:28:16 agendum 3 closed 18:28:17 I see 4 items remaining on the agenda; the next one is 18:28:17 4. -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates [from agendabot] 18:28:19 zakim, next item 18:28:19 agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot] 18:28:19 I can't comment on that because it doesn't look like a github issue to me. 18:28:36 jamesn: none here, anyone want to propose....? 18:28:46 zakim, close this item 18:28:46 agendum 4 closed 18:28:47 I see 3 items remaining on the agenda; the next one is 18:28:47 5. Webkit landed ARIA notifty and Gecko is implementing! \o/ [from agendabot] 18:28:49 zakim, next item 18:28:49 agendum 5 -- Webkit landed ARIA notifty and Gecko is implementing! \o/ -- taken up [from agendabot] 18:29:05 jamesn: an fyi! yay! 18:29:10 q+ 18:29:32 Ack spectranaut_ 18:29:41 ChrisCuellar has joined #aria 18:30:09 https://github.com/w3c/aria/pull/2577 18:31:27 spectranaut_: there were questions from jamie teh and Jacques just answered, and Jacques will make one more update in response and we will land 18:31:41 smockle: but should we actually document that thing? 18:31:46 Matt_King: I think so 18:32:02 smockle: (explains why he thinks it should not be explicit) 18:32:29 keithamus: we have a warning in the dev console .... 18:32:43 jamesn: it should be valid for pages to fire it, it's jut not going to be delivered 18:32:51 keithamus: its an opp to educate users 18:33:12 jamesn: and you should be firing so many that that is a problem 18:33:45 Matt_King: we have a lot of useful notes in teh ARIA spec for authors, so whether or not it belongs in the spec is an editorial call. it is nice to have those, though 18:33:46 q+ 18:33:52 jamesn: I think this belongs in the spec 18:33:58 Jacques: so is this a note in the spec? 18:34:08 jamesn: I think it should be normative, maybe a should or should not 18:34:23 Jacques: sounds good to me 18:34:31 q+ 18:34:35 jamesn: I think it's best practice 18:34:52 Jacques: if someone is doing this.. they should be aware it won't get to the user... 18:35:02 jamesn: if it is in the background, the visual user won't get it 18:35:02 q- 18:35:21 q+ 18:35:22 jamesn: what do folks thinks? 18:35:29 ack Jacques 18:35:34 Ack scott 18:35:35 ack scott 18:36:07 scott: I would agree it should be in the spec and a MUST, it would lead to problems with users if other pages are screaming at you 18:36:18 scott: I was thinking about (??) messages.... 18:36:25 scott: (scribe missing) 18:36:32 status messages 18:36:55 scott: In APG examples, we will need to call out something related to this 18:37:01 specifically SC 4.1.3 18:37:21 jamesn: we need to help with specific technique for WCAG 18:37:24 q+ 18:37:29 scott: I know they will appreciate it 18:37:59 ack me 18:38:01 mcking: if it is a MUST NOT, is that eliminating a use case we are not thinking of by being to restrictive 18:38:02 Ack jcraig 18:38:09 q+ 18:38:16 jcraig: yeah, good job matt, that is what I was going to say 18:40:24 jcraig: there is some level of support for AriaNotify that can use existing notification mechanism, other things that might be adopted by screen readers and platforms, AT portions of AriaNotify. one of the things we discussed internally was exactly this, what are the usecase for whether you want to monitor, not a background tab, but background windw -- the window is rendered, a sighted user can see it, maybe someone wants to monitor it. 18:40:24 Front most tab or window. it would be premature to lock a limitation to the spec for the exact reasons -- leave flexible for implementers to handle annoyance factors 18:40:28 q+ 18:40:29 jcraig: voiceover has activities 18:40:38 jcraig: might be premature 18:41:08 +1 for should not 18:41:12 jamesn: if we made it should not, allows browsers or AT or expose things in the future...? 18:41:35 jcraig: you are putting this change on the engine, I think the AT should make the decision 18:42:22 jcraig: putting the should not requirement on the engine, is more rigid and less flexible then allowing the AT to ignore things in certain contents. The engine can throw out notifications, the AT should decide what to communicate or pass or put in background log 18:42:40 jcraig: I think this should be a note, basically 18:42:56 Ack jamesn 18:43:39 jamesn: I want to confirm, the implementations today work the same as a live region implementation today, which doesn't fire notification on background tabs... so we are following the same, would that be a reasonable way of doing this 18:43:43 Ack smockle 18:44:01 q+ Matt_King 18:44:06 smockle: I was going to raise a similar clarification, inactive tabs vs inactive window, two browser windows tiled, wanting notifications from both 18:44:21 Agenda? 18:44:23 https://github.com/WebKit/standards-positions/issues/370#issuecomment-3229961127 18:44:29 q+ to ask if talking about author req or UA req 18:44:34 smockle: secondly, everything said around allowing this to not be prescriptive, reminds me of webkit standard perspective 18:44:54 smockle: that different technologies can handle annoyance differently 18:45:13 Ack Matt_King 18:45:13 Matt_King, you wanted to ask if talking about author req or UA req 18:45:16 smockle: and this is an opportunity for competitive innovation 18:45:20 q+ 18:45:57 Ack me 18:46:01 Matt_King: I was confused by the beginning of the conversation... I haven't see the language ... are we talking about author or user agent requirement. If it is an authoring requirement, it should be a should not, if it is a UA requirement, that is different 18:46:14 jamesn: authors don't know whether tabs are in the background 18:46:22 jamesn: what should we do....? 18:46:26 q+ 18:46:28 The WebKit standards position reference that Clay mentioned: https://github.com/WebKit/standards-positions/issues/370#issuecomment-3229961127 18:46:29 q+ 18:46:32 "concern-annoyance: misuse of this API may annoy or pester the user (a larger version of the same problem exists with Live Regions); browsers and/or assistive technologies should allow users to disallow usage by domain, but the spec should not be prescriptive about how this annoyance remediation is achieved. This is an opportunity for innovation and competitive differentiation." 18:46:48 Matt_King: we need to be consistent, that effects the AT, if each user agent is doing something different 18:46:52 Ack scott 18:46:54 q- 18:47:37 q+ 18:47:51 scott: I actually changed my mind, I think really my concern about author guidance, should that be added here -- that people should know that it will be easier to use to communicate to users, it is easier to not know how info is being communicated by users. make sure people are careful where they can find such messages are coming from. 18:47:57 Ack Jacques 18:48:00 scott: I think we don't need a user agent requirement 18:49:13 Jacques: I'm not clear... I'm not sure I'm clear on what I think. I agree UA and ATs, they should have the ability to do the filtering they want to do. Authors should be aware filtering can happen. would a note saying useragents and AT can do this filtering for inactive or background tabes. 18:49:31 Jacques: authors need to be aware this can happen, no restrictions 18:49:41 jcraig agrees 18:49:53 Matt_King: saying AT "might" do this is clear enough to me 18:50:05 Matt_King: but the UA need to be doing the same thing with the same web page. 18:50:26 q+ 18:50:52 ack smockle 18:50:56 jamesn: (scribe missed) 18:51:06 smockle: do we define what UA should do for live regions? 18:51:08 jamesn: no 18:51:24 q+ 18:51:32 Ack spectranaut_ 18:52:01 spectranaut_: I suggest we merge and do this in a follow up 18:52:22 Jacques: I'll make a follow up note 18:53:49 RESOLVED: We will land AriaNotify and deal with the issue about what user agents should do with notifications from background tabs in a follow up, or what note to add to help authors understand filtering, in a follow up PR. 18:54:17 GitHub: https://github.com/w3c/aria/pull/2577 18:54:44 zakim, next item 18:54:44 agendum 6 -- -> Should :target-current pseudo class also imply aria-current=true on an active scroll marker? https://github.com/w3c/aria/issues/2710 -- taken up [from agendabot] 18:55:33 Jacques: I added this for lucas 18:55:45 sarah has joined #aria 18:55:56 q+ 18:56:07 dgrogan: this came out of a blog post from sarah.... 18:56:08 q+ 18:56:25 dgrogan: we implemented the suggestion, CSS wanted something firmer from the accessibility group 18:56:38 dgrogan: we think it is a good recommendation and it solves a real user problem 18:56:50 dgrogan: we'd like to hear agreement or just that no one objects 18:56:58 Ack sara 18:57:35 q+ to agree with using the same platform mapping, but to point out a potential problem with ARIA mapping conflicts re: 'strong native semantics' 18:58:02 sarah: I was curious, there was discussion about different implicit roles, there has been talk about scroll markers having different mapped roles both on how they are used, or maybe adding something for authors to change what type of control the scroll marker would be, even those with role none, because aria-current is not valid on every possible role proposed for scroll markers. 18:58:36 Daniil: explains....... (scribe missed) 18:58:51 sarah: ok this doesn't exactly apply to what I'm talking about (????) 18:58:59 Ack jcraig 18:58:59 jcraig, you wanted to agree with using the same platform mapping, but to point out a potential problem with ARIA mapping conflicts re: 'strong native semantics' 18:59:00 ack me 19:00:38 jcraig: so what it currently says, the last paragraph, we should set aria-current=true, setting the dom or content attribute I don't really agree with, that would be a surprised to authors if those attributes change unexpectedly. the native implementation of target current should use the same platform mappings that aria-current uses. don't cross the streams, don't mix and match, aria has this concept called strong native semantics -- 19:00:38 html wins over ARIA in some cases 19:00:52 jcraig: in this particular case, some is coming from pseudo class, dom, etc 19:01:21 q+ 19:01:27 jcraig: ultimately, there should be a mapping. maybe we will have a scenario where and author mixed the two... we probably want to do what the author wants 19:01:39 zakim, close queue 19:01:39 ok, spectranaut_, the speaker queue is closed 19:01:55 Daniil: just for styling.... 19:02:10 jcraig: visiting links are just for styling, but those are communicated to AT 19:02:18 jcraig: this should not change the content attributes 19:02:35 jamesn: no resolution yet, we need to discuss more next week 19:02:53 present+ 19:02:58 present+ 19:03:10 RRSAgent, make minutes 19:03:11 I have made the request to generate https://www.w3.org/2026/01/22-aria-minutes.html spectranaut_ 19:03:50 visiting links are just for styling, but those are communicated to AT/you said this is "just for styling" but many think :visited links are just for styling, but those are communicated to AT; so this can be the same in the native mapping/ 19:04:17 s/this should not change the content attributes/this should NOT change any content attributes like aria-current/ 19:05:10 s/don't cross the streams,/add an author note to not cross the streams,/ 19:05:18 rrsagent, make minutes 19:05:20 I have made the request to generate https://www.w3.org/2026/01/22-aria-minutes.html jcraig 19:07:16 bkardell has joined #aria 19:14:21 zakim, end meeting 19:14:21 As of this point the attendees have been katez, smockle, Jacques, giacomo-petri, Adam_Page, aardrian, dgrogan, sarah, scott, Francis_Storr, Daniel, filippo-zorzi, pkra, CurtBellew, 19:14:25 ... Rahim, Matt_King, Siri 19:14:25 RRSAgent, please draft minutes v2 19:14:26 I have made the request to generate https://www.w3.org/2026/01/22-aria-minutes.html Zakim 19:14:31 I am happy to have been of service, spectranaut_; please remember to excuse RRSAgent. Goodbye 19:14:31 Zakim has left #aria 21:02:07 ChrisCuellar has joined #aria 21:34:07 ChrisCuellar has joined #aria 21:50:06 ChrisCuellar has joined #aria 23:40:30 ChrisCuellar has joined #aria