Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
github 2863
@lola This should be a draft but those don't get added to the agenda. Should this get changed to a generic call?
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.
github 2862
@Daniel: This could use a couple eyes on it, still making some considerations, but needs a review
github core-aam 2860
James Nurthen: Needs some reviews, it's a section on translation.
github 2857
James Nurthen: This already has reviewers, so reminder to review it
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
tinyurl.com/wpt-a11y
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: Do we want to setup another deep dive? Nope
Security Horizontal Review
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
<Jacques> Also discussed in the PR thread here: https://
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.
<Jacques> This shipped in chromium and firefox, I think webkit was behind a flag
Daniel: I could try to take a pass at adding this to the security section of the doc
Jacques: I am happy to assist and answer questions if needed
jamesn: You can pull from the previous discussions which you linked to
interactive elements contained in button?
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.)
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
jcraig: Aren't we concerned about webcompat? That seems like a pretty major change
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
spectranaut_: 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.
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
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.
<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 new attribute is better.
giacomo-petri: Based on that I'm not sure what we want to do with this.
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.
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.
Adrian Roselli: Has the research been done on the different ways different cases are handled across browsers?
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.
James Nurthen: A button inside a button is an exception, but there are other cases which are different.
Matt_King: I thought interactive inside a button isn't allowed by the content model?
I just lost internet so someone else will have to pick up scribing.
<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 specific input types with buttons inside other input fields... type=search, type=number (stepper), etc. and atomic-focus being a separate issue
Matt_King: can we narrow this down a bit?
spectranaut_: we can try for buttons
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.
… 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.
… "atomic focus" is a separate issue from exposure on accessibility tree.
… so there are some scenarios where this doesn't pose issue.
… to rephrase. I was thinking about having a new attribute. But that's effectively what aria-atomic is, for live regions.
… comes down to "present this as a whole or as separate parts that can announce themselves"
… this seems smilar. Is this a leaf node i.e. atomic or is there more underneath.
… if we have a new state or re-use atomic, would give the flexibility to allow author overrides where authors know better than UAs.
spectranaut_: I wonder if we want an attribute to make children presentational or to allow children.
jcraig: right. 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.)
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.
Matt_King: to clarify: is chrome exposing both interactive and static rich content?
spectranaut_: both
Matt_King: for interactives, they break the content model. What do browsers do? For button elements inside button elements, what happens?
… do we have to care?
giacomo-petri: you cannot nest buttons in markup but you can nest buttons using javascript insertion. I don't know what happens there.
… I think in the past firefox might have had keyboard traps.
Matt_King: so that sounds like we do need to care about this in ARIA?
Stefan: for chrome, the second button is just rendered after the first. Maybe other engines are different.
… but chrome is also inconsistent. with option, it renders the text part in the inner part but the button vanishes.
spectranaut_: in one of the previous discussions somebody pointed out that people use ARIA intentionally to get around nested buttons in HTML.
<jcraig> xzibit: yo i heard you like buttons, so i put buttons in your buttons.
Stefan: I think we're not strict enough in the spec which gives people this idea.
… it gives people the wrong idea because browsers let them.
jcraig: I wonder if people tried tables in buttons, since those aren't clickable per-se, but whether screenreaders can navigate the table.
jamesn: there's also a discrepancy between link in button vs button in link
Matt_King: how is this supposed to work?
jamesn: we have 3-4 options now
jcraig: using a new attribute would likely cause the least webcompat breakage.
jamesn: I think that depends a bit on the timeline.
jcraig: right.
jamesn: we should ask Chromium when this change happened.
<Jacques> I can take a look at the history to see when this changed in chromium.
<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 :)
Matt_King: if browsers sometimes unnest, is that an option for the ARIA side?
spectranaut_: that seems like another option.
Define proper AT exposure for `aria-colindex` when web authors specific this value on a row
jamesn: this seems very narrow.
spectranaut_: let's punt.