16:14:55 <RRSAgent> RRSAgent has joined #aria
16:15:00 <RRSAgent> logging to https://www.w3.org/2026/08/06-aria-irc
16:15:00 <Zakim> RRSAgent, make logs Public
16:15:01 <Zakim> Meeting: ARIA WG
16:15:02 <jamesn> Agendabot, find agenda
16:15:02 <agendabot> jamesn, OK. This may take a minute...
16:15:30 <agendabot> Sorry, I did not find an agenda.
16:15:58 <jamesn> agenda: https://lists.w3.org/Archives/Public/public-aria/2026Aug/0001.html
16:15:58 <agendabot> jamesn, sorry, could not get https://lists.w3.org/Archives/Public/public-aria/2026Aug/0001.html (code 429).
16:21:01 <jamesn> Agenda+ [New PR Triage](https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-07-30+repo:w3c/aria&type=Issues)
16:21:01 <jamesn> Agenda+[WPT Open PRs](https://tiny.url/wpt-a11y)
16:21:01 <jamesn> Agenda+[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
16:21:01 <jamesn> Agenda+[Security Horizontal Review](https://github.com/w3c/aria/issues/2861)
16:21:01 <jamesn> Agenda+[interactive elements contained in button?](https://github.com/w3c/aria/issues/2856)
16:21:02 <jamesn> Agenda+[Define proper AT exposure for `aria-colindex` when web authors specific this value on a row](https://github.com/w3c/core-aam/issues/266)
16:21:02 <jamesn> Agenda+ [Unclear purpose of `aria-valuemin` and `aria-valuemax` when `aria-valuetext` is used](https://github.com/w3c/aria/issues/1128)
16:59:36 <filippo-zorzi> filippo-zorzi has joined #aria
16:59:56 <giacomo-petri> giacomo-petri has joined #aria
17:00:12 <filippo-zorzi> present+
17:00:33 <lola> lola has joined #aria
17:01:20 <Steven_Lambert> Steven_Lambert has joined #aria
17:01:23 <Stefan> Stefan has joined #aria
17:02:02 <Matt_King> Matt_King has joined #aria
17:02:20 <Jacques> Jacques has joined #aria
17:03:05 <markrogers> markrogers has joined #aria
17:03:17 <katez> katez has joined #aria
17:03:19 <aardrian> aardrian has joined #aria
17:03:21 <katez> present+
17:03:25 <Jacques> present+
17:03:27 <aardrian> present+
17:04:01 <Stefan> present+
17:04:15 <front-endian-jane> scribe+
17:04:18 <front-endian-jane> present+
17:04:18 <spectranaut_> present+
17:04:32 <front-endian-jane> zakim, next item
17:04:32 <Zakim> agendum 1 -- [New PR Triage](https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-07-30+repo:w3c/aria&type=Issues) -- taken up [from jamesn]
17:04:32 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:04:49 <Daniel> present+
17:05:35 <front-endian-jane> github 2863
17:05:47 <front-endian-jane> @lola
17:06:33 <front-endian-jane> s/@lola/@lola This should be a draft but those don't get added to the agenda. Should this get changed to a generic call?
17:08:08 <front-endian-jane> James Nurthen: The new PR thing pulls everything that was created in the last week, so you can make things draft, but they can get lost because reviewers aren't assigned. Add the agenda tag when you want it reviewed so we can take a look at it.
17:08:31 <front-endian-jane> github 2862
17:08:57 <front-endian-jane> @Daniel: This could use a couple eyes on it, still making some considerations, but needs a review
17:09:29 <front-endian-jane> github core-aam 2860
17:09:52 <front-endian-jane> James Nurthen: Needs some reviews, it's a section on translation.
17:10:45 <front-endian-jane> github 2857
17:11:06 <front-endian-jane> James Nurthen: This already has reviewers, so reminder to review it
17:11:11 <front-endian-jane> zakim, next item
17:11:11 <Zakim> agendum 2 -- [WPT Open PRs](https://tiny.url/wpt-a11y) -- taken up [from jamesn]
17:11:11 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:12:05 <front-endian-jane> tinyurl.com/wpt-a11y
17:12:36 <Francis> present+
17:12:58 <front-endian-jane> zakim, next item
17:12:58 <Zakim> agendum 3 -- [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from jamesn]
17:12:58 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:13:42 <front-endian-jane> jamesn: Do we want to setup another deep dive?  Nope
17:13:45 <front-endian-jane> zakim, next item
17:13:45 <Zakim> agendum 3 was just opened, front-endian-jane
17:14:07 <jamesn> zakim, close this item
17:14:07 <Zakim> agendum 3 closed
17:14:08 <Zakim> I see 4 items remaining on the agenda; the next one is
17:14:08 <Zakim> 4. [Security Horizontal Review](https://github.com/w3c/aria/issues/2861) [from jamesn]
17:14:14 <jamesn> Zakim, next item
17:14:14 <Zakim> agendum 4 -- [Security Horizontal Review](https://github.com/w3c/aria/issues/2861) -- taken up [from jamesn]
17:15:33 <Daniel> q+
17:15:39 <front-endian-jane> jamesn: This is all about the permission policy on ARIA notify. The concern is that the permission defaults to *, which means there is cross frame access, which is normally an issue, and we haven't explicitly documented in the security documentation about what we are doing and why
17:15:51 <front-endian-jane> ack Daniel
17:15:55 <jamesn> Ack Daniel
17:16:33 <Jacques> Also discussed in the PR thread here: https://github.com/w3c/aria/pull/2577#discussion_r2700659989
17:17:04 <front-endian-jane> Daniel: Where are we at in terms of implementations? Last I tried it, it was under a flag in Chrome. I put a comment on what my rational was for the security relaxation. I want to know if that is right or if there is anything else that I missed.
17:17:19 <Jacques> This shipped in chromium and firefox, I think webkit was behind a flag
17:18:05 <front-endian-jane> Daniel: I could try to take a pass at adding this to the security section of the doc
17:18:20 <front-endian-jane> Jacques: I am happy to assist and answer questions if needed
17:18:47 <front-endian-jane> jamesn: You can pull from the previous discussions which you linked to
17:18:57 <front-endian-jane> zakim, next item
17:18:57 <Zakim> agendum 5 -- [interactive elements contained in button?](https://github.com/w3c/aria/issues/2856) -- taken up [from jamesn]
17:19:23 <Stefan> q+
17:20:15 <front-endian-jane> spectranaut_: Yesterday I looked at all the links that were provided on the Github. This is a summary of my research. I wanted to see if we could make any headway on this topic. (I haven't read your comment yet Giacomo.)
17:21:09 <giacomo-petri> q+
17:21:26 <front-endian-jane> spectranaut_: There was an informed request from Wilco, but people wanted to do some more research onto child presentational elements. Giacomo's PR contains language around this which does away further with children presentational
17:21:35 <front-endian-jane> jcraig: That seems like a major change
17:22:37 <jamesn> Q?
17:22:37 <jcraig> s/That seems like a major change/Aren't we concerned about webcompat? That seems like a pretty major change/
17:22:42 <jcraig> q+
17:23:11 <aardrian> q+
17:23:12 <Matt_King> q+
17:24:34 <jcraig> q+ to ask if anyone diagnosed when that change happened in Chrome?
17:24:47 <front-endian-jane> spectranaut_: There is a web compat issue where different browsers expose things differently. One possible solution is to do away with children presentational, but I'm not saying we should. One reason we may want to is the ARIA WG has two directives, we want to present information like rich content and buttons to ATs, and to give them the ability to do something with it. Right now some ATs can't handle rich content in children
17:24:47 <front-endian-jane> presentational, but some browsers can't handle it. We could do a bunch of research and have more refined presentational roles, or we could eliminate the children presentation rule (it is a "should", not a hard requirement in the spec) and always expose them to the ATs and let them handle it.
17:25:09 <jamesn> Ack Stefan
17:25:37 <front-endian-jane> s/presentational, but some/spectranaut_: presentational, but some/
17:25:41 <jcraig> q+ to wonder if this breaks the webcompat contract (breaking old content), and if an explicit new attribute is better.
17:26:29 <front-endian-jane> Stefan: This would also cause issues for the validators, it is unclear where to point developers too when there are validator issues due to a lack of a clear directive
17:26:33 <Stefan> q-
17:26:40 <jamesn> Ack gia
17:27:20 <pkra> pkra has joined #aria
17:27:23 <pkra> present+
17:27:36 <front-endian-jane> giacomo-petri: About my PR, the intent was to represent what is happening right now with user agents. I wanted to clarify that form an authoring point of view it's a violation, but I got pushback that things should be exposed, which is why some user agents may do it.
17:28:09 <jcraig> ack me
17:28:09 <Zakim> jcraig, you wanted to ask if anyone diagnosed when that change happened in Chrome? and to wonder if this breaks the webcompat contract (breaking old content), and if an explicit
17:28:12 <Zakim> ... new attribute is better.
17:28:13 <twilco> twilco has joined #aria
17:28:15 <front-endian-jane> giacomo-petri: Based on that I'm not sure what we want to do with this.
17:29:30 <front-endian-jane> jcraig: I wanted to ask if any knows when the change happened in Chrome? This has been the standard for the entirety of the web, and if it has changed that could break old websites.
17:31:18 <jamesn> Ack aad
17:31:28 <jamesn> Ack aa
17:32:29 <front-endian-jane> jcraig: We could add an explicit attribute instead which would keep older websites supported and let us handle other cases beyond the button case listed.
17:33:05 <jcraig> q+ to suggest maybe expanding the use of aria-atomic beyond live regions?
17:33:19 <front-endian-jane> Adrian Roselli: Has the research been done on the different ways different cases are handled across browsers?
17:34:08 <jcraig> q+ to say b/c button, img, have always been atomic=true by default
17:34:28 <front-endian-jane> spectranaut_: No, people have suggested that, but no one has. Yes, we need to do the research, but it will likely be a large amount of work. Maybe we can do an initiative with multiple people.
17:35:25 <jamesn> Ack matt
17:35:38 <front-endian-jane> James Nurthen: A button inside a button is an exception, but there are other cases which are different.
17:35:56 <front-endian-jane> Matt_King: I thought interactive inside a button isn't allowed by the content model?
17:36:37 <Stefan> q+
17:36:57 <giacomo-petri> q+
17:37:14 <front-endian-jane> I just lost internet so someone else will have to pick up scribing.
17:37:31 <jcraig> q+ to mention the specific input types with buttons inside other input fields... type=search, type=number (stepper), etc. and atomic-focus being a separate issue
17:37:52 <pkra> scribe+
17:38:02 <jamesn> Ack jc
17:38:02 <Zakim> jcraig, you wanted to suggest maybe expanding the use of aria-atomic beyond live regions? and to say b/c button, img, have always been atomic=true by default and to mention the
17:38:02 <jcraig> ack me
17:38:05 <Zakim> ... specific input types with buttons inside other input fields... type=search, type=number (stepper), etc. and atomic-focus being a separate issue
17:38:22 <pkra> Matt_King: can we narrow this down a bit?
17:38:27 <pkra> spectranaut_: we can try for buttons
17:39:05 <giacomo-petri> q-
17:39:12 <pkra> jcraig: re new attribute. aria-atomic basically does this, just specific to live regions. We have enumerated a lot of scenarios. There's button. I called out image before. Nested interactives.
17:39:42 <pkra> ... they have always been "atomic=true" by default. Browsers changing is a compat risk. There's also input types. E.g. search has a clear button.
17:40:01 <pkra> ... "atomic focus" is a separate issue from exposure on accessibility tree.
17:40:24 <pkra> ... so there are some scenarios where this doesn't pose issue.
17:41:07 <pkra> ... to rephrase. I was thinking about having a new attribute. But that's effectively what aria-atomic is, for live regions.
17:41:28 <pkra> ... comes down to "present this as  a whole or as separate parts that can announce themselves"
17:41:50 <pkra> ... this seems smilar. Is this a leaf node i.e. atomic or is there more underneath.
17:42:12 <giacomo-petri> q+
17:42:27 <Matt_King> q?
17:42:32 <pkra> ... if we have a new state or re-use atomic, would give the flexibility to allow author overrides where authors know better than UAs.
17:42:44 <Matt_King> q+
17:43:00 <pkra> spectranaut_: I wonder if we want an attribute to make children presentational or to allow children.
17:43:15 <jamesn> Ack Stefan
17:43:17 <pkra> jcraig: right. I would phrase it as chrome prematurely rolling it out and maybe rolling it back.
17:43:53 <giacomo-petri> q-
17:43:58 <jamesn> Ack Matt_King
17:44:00 <pkra> Stefan: re Matt. I'd prefer if we could have role=option hosting a role=button. That's currently prohibited. It might help ease some aria-actions cases.
17:44:20 <pkra> Matt_King: to clarify: is chrome exposing both interactive and static rich content?
17:44:22 <pkra> spectranaut_: both
17:44:36 <giacomo-petri> q+
17:44:40 <Stefan> q+
17:44:48 <pkra> Matt_King: for interactives, they break the content model. What do browsers do? For button elements inside button elements, what happens?
17:44:53 <jamesn> Ack giacomo-petri
17:44:54 <pkra> ... do we have to care?
17:45:16 <jcraig> q+
17:45:18 <pkra> giacomo-petri: you cannot nest buttons by markup but by javascript. I don't know what happens there.
17:45:29 <pkra> ... I think in the past firefox might have had keyboard traps.
17:45:42 <pkra> Matt_King: so that sounds like we do need to care about this in ARIA?
17:45:43 <jamesn> Ack Stef
17:46:10 <pkra> Stefan: for chrome, the second button is just rendered after the first. Maybe other engines are different.
17:46:23 <jcraig> s/you cannot nest buttons by markup but by javascript./you cannot nest buttons in markup but you can nest buttons using javascript insertion./
17:46:32 <pkra> ... but chrome is also inconsistent. with option, it renders the text part in the inner part but the button vanishes.
17:47:13 <jamesn> Q?
17:47:39 <pkra> spectranaut_: in one of the previous discussions somebody pointed out that people use ARIA intentionally to get around nested buttons in HTML.
17:47:57 <jcraig> xzibit: yo i heard you like buttons, so i put buttons in your buttons.
17:48:10 <pkra> Stefan: I think we're not strict enough in the spec which gives people this idea.
17:48:28 <pkra> ... it gives people the wrong idea because browsers let them.
17:48:53 <jamesn> ack jc
17:49:25 <pkra> jcraig: I wonder if people tried tables in buttons. If screenreaders can navigate the table.
17:50:03 <pkra> jamesn: there's also a discrepancy between link in button vs button in link
17:50:12 <pkra> agenda?
17:50:49 <pkra> Matt_King: how is this supposed to work?
17:51:34 <pkra> jamesn: we have 3-4 options now
17:51:45 <pkra> jcraig: the attribute should be least breakage.
17:52:01 <pkra> jamesn: I think that depends a bit on the timeline.
17:52:03 <pkra> jcraig: right.
17:52:26 <pkra> jamesn: we should ask Chromium when this change happened.
17:53:22 <Jacques> I can take a look at the history to see when this changed in chromium.
17:53:53 <Francis> Gemini has an instance of <div role="button" …><button></button></div> so you can try out the issue there at the same time as asking about the change history :)
17:54:13 <jamesn> Q?
17:54:51 <pkra> Matt_King: if browsers sometimes unnest, is that an option for the ARIA side?
17:55:03 <pkra> spectranaut_: that seems like another option.
17:55:09 <pkra> zakim, next item
17:55:09 <Zakim> agendum 6 -- [Define proper AT exposure for `aria-colindex` when web authors specific this value on a row](https://github.com/w3c/core-aam/issues/266) -- taken up [from jamesn]
17:56:10 <pkra> jamesn: this seems very narrow.
17:56:38 <pkra> spectranaut_: let's punt.
17:57:21 <pkra> zakim, end meeting
17:57:21 <Zakim> As of this point the attendees have been filippo-zorzi, katez, Jacques, aardrian, Stefan, front-endian-jane, spectranaut_, Daniel, Francis, pkra
17:57:24 <Zakim> RRSAgent, please draft minutes v2
17:57:26 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/06-aria-minutes.html Zakim
17:57:33 <Zakim> I am happy to have been of service, pkra; please remember to excuse RRSAgent.  Goodbye
17:57:33 <giacomo-petri> present+
17:57:33 <Zakim> Zakim has left #aria
17:58:10 <markrogers> markrogers has left #aria
22:19:30 <jcraig> s/the attribute should be least breakage./using a new attribute would likely cause the least webcompat breakage./
22:20:41 <jcraig> s/I wonder if people tried tables in buttons. If screenreaders can navigate the table./I wonder if people tried tables in buttons, since those aren't clickable per-se, but whether screenreaders can navigate the table./
22:20:52 <jcraig> rrsagent, make minutes
22:20:54 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/06-aria-minutes.html jcraig
22:24:18 <jcraig> s/I would phrase it as chrome prematurely rolling it out and maybe rolling it back./I'm suggesting chrome may have prematurely rolled out a webcompat-breaking change and maybe should roll it back. (unless perhaps, its been out for years without known issues.)/
22:24:24 <jcraig> rrsagent, make minutes
22:24:25 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/06-aria-minutes.html jcraig
22:24:49 <jcraig> present+
22:24:51 <jcraig> rrsagent, make minutes
22:24:52 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/06-aria-minutes.html jcraig