– DRAFT –
ARIA WG

New Issue Triage

<sarah_higley> jamesn: What the hell is this Scott? It's a chore, we don't need to talk about it, or that one

<sarah_higley> jamesn: Should dialog or element aria-modal cause live regions...

<sarah_higley> scottono: I'm interested in other peoples' opinions. People trying to use live regions outside of modal dialogs

<sarah_higley> jamesn: we need to replace hacky live region usage with something better, and then we don't have this problem

<sarah_higley> jamesn: we need to make it so people don't need to use hidden live regions, only things that are visible on the screen

<sarah_higley> Matt_King: question about modal state

<sarah_higley> scottono: a team has a script that inserts a live region at the end of the DOM, and they open a modal, and then the live region announcement isn't made b/c they're inserting content into an inert document

<sarah_higley> Matt_King: the hidden live region doesn't work if it's aria-hidden, right?

<sarah_higley> jamesn: correct

<sarah_higley> Matt_King: is this an element with the HTML role of dialog?

<sarah_higley> scottono: in this context, an aria dialog with aria-modal=true, so it's hiding the content outside the dialog

<sarah_higley> Matt_King: why is that, aria-modal doesn't actually hide content

<sarah_higley> Matt_King: it doesn't affect the accessibility tree outside the dialog, right?

<sarah_higley> scottono: I don't think that's how it's been implemented

<sarah_higley> scottono: maybe that's where the disconnect is here

<sarah_higley> Matt_King: it's author responsibility if you're going to make the background inert. If you have a role=dialog and aria-modal=true, we don't expect that to have an impact on the browser's a11y tree. According to the ARIA spec it doesn't expect the author would remove content outside the dialog from the a11y tree

<sarah_higley> Matt_King: not like aria-hidden would do

<sarah_higley> scottono: I understand what you're saying, I just don't think it's been implemented that way

<sarah_higley> Matt_King: I would consider that a browser bug if they remove content outside the dialog

<sarah_higley> jamesn: isn't that what we've been telling people to do since forever

<sarah_higley> scottono: in most cases, we are telling authors content outside the dialog needs to be inert and hidden from the a11y tree

<sarah_higley> scottono: so it doesn't surprise me at all that this is how it's been implemented

<sarah_higley> sarah_higley: in terms of user experience, that's also what we want, right?

<sarah_higley> Matt_King: this could also be a reason there's also unintended side effects. THere's also the case where with some screen readers you could un-restrict and see content outside the currently focused window

<sarah_higley> Matt_King: you could still get outside the window and know what's there

<sarah_higley> Matt_King: we're making an assumption when we do that that the content has been made unreadable who can see as well. And it seems to me like there should be a dependency on if it's visibly unreadable that seems like the right behavior

<sarah_higley> Matt_King: because trimming it from the accessibility tree puts it 100% out of reach

<sarah_higley> Matt_King: and I kind of worry about the situations where the dialog incorrectly remains open, where there's bugs

<sarah_higley> Matt_King: and the focus is outside the dialog and the dialog remains open

<sarah_higley> Matt_King: I understand the objective, I'm concerned about the side effects in practice. It seems the way the spec is currently written it seems like a bug to me

<sarah_higley> jamesn: let's talk about this in the new year when we have representation from Chromium here

<sarah_higley> jamesn: let's table this, and potentially this is a deep dive topic. Let's tackle live regions in the new year. Part of this is aria-modal. It wouldn't been better if AT handled this, but they don't

<sarah_higley> scottono: I did also mention in my response to that issue, there could also have been aria-hidden=sortof. We need to both make it so it's difficult to allow for virtual cursor to access content that shouldn't be accessed, but allow it to be accessible if someone does get to it

<sarah_higley> scottono: I agree this is a new year topic

<sarah_higley> Matt_King: I just want to make sure we don't dismiss it as not a bug, and there are complicating factors

<sarah_higley> jamesn: last one: calrify use for aria-rowindex on cell/gridcell elements

<sarah_higley> scottono: this is to get clarity on why aria-rowindex on cells/gridcells. In the example the row that the cells are in have aria-rowindex, so at best the attribute is redundant

<sarah_higley> scottono: this came up because a team wanted to mark a table up without row elements

<sarah_higley> scottono: it would work a lot better with CSS flexbox and grid

<sarah_higley> Matt_King: it's kind of a creative idea. I don't know if it should be considered because the table is so complicated

<sarah_higley> scottono: I don't know if I condone this, but some developers question why rows are the way tables are made. Why couldn't it be columns? And if one were to ignore decades of how this is done and make tables via columns, this would be a way to correct the rows

<sarah_higley> Matt_King: think of how this is like if you're making a spreadsheet, and you copy and paste columns. This would make it so easy

<sarah_higley> sarah_higley: I was talking with someone yesterday who wanted to do the same thing with trees -- treeitems are all flat, and everything is done with ARIA

<sarah_higley> Matt_King: it's a creative solution, and similar to treegrid

<sarah_higley> jamesn: maybe this is a road we need to go down

<sarah_higley> Matt_King: you could literally use indexing to fix the random DOM order of your table

<sarah_higley> Matt_King: she didn't minute the statement "don't minute this"

<sarah_higley> jamesn: OK, I've agenda'd it for the new year. It sounds like a deep dive where we need the right people in the conversation than an agenda though

<sarah_higley> jamesn: or it can be an agenda to start, and if there's any hope we can deep dive it

<sarah_higley> jamesn: we need James Teh, that's why I want to deep dive it and do an afternoon call

<Zakim> jamesn, you wanted to remind folks this is triage

New PR Triage

<sarah_higley> jamesn: clarify image mappings

<sarah_higley> scottono: this is resolving that issue when lol what happens when an image doesn't have a src defined

<sarah_higley> scottono: I went into the AAM spec to call that out, and then opened up a rabbit hole b/c it's not whether the image has an alt attr, it's whether it has a name to expose it as an image or not.

<sarah_higley> jamesn: who wants to review

<sarah_higley> sarah_higley: I hate myself, I can review

<sarah_higley> jamesn: next, clarification label and for attribute. We already have reviewers on this

Last Meeting of the year - Deep Dive planning for the new year?

<sarah_higley> jamesn: this is the last meeting of the year, congratulations

<sarah_higley> scottono: we made it!

<sarah_higley> jamesn: if anyone wants to propose anything, they can always email me or Valerie, it doesn't need to be in the meeting

<sarah_higley> ~silence~

GH Summary email

<sarah_higley> jamesn: has anyone been seeing the github summary email?

<sarah_higley> scottono: oh, I delete it

<sarah_higley> jamesn: so I take it you find it completely useles

<sarah_higley> scottono: when it just lists the things I did, I'm kinda like "yeah, I know"

<sarah_higley> jamesn: I can just send it to the chairs instead, because I find it useful personally

<sarah_higley> scottono: I spend so much time trolling github that I don't need it

<sarah_higley> jamesn: has anyone else seen it?

<sarah_higley> Matt_King: I haven't read it yet. It sounds like it might be useful because there are a lot of threads where I delete the whole thread

<sarah_higley> jamesn: I subscribe to the one for respec, so I can pay attention once per week

<sarah_higley> jamesn: so it's a way for people on the periphery to keep plugged in to what's going a little bit. If you look at it.

<sarah_higley> Matt_King: I agree with the assessment

<sarah_higley> MarkMcCarthy: I filter all my stuff to different folders, and only check before the meeting, so thanks for mentioning it

<sarah_higley> jamesn: I find it useful for surfacing old topics that have become active again

<sarah_higley> jamesn: OK

ARIA ACT Rules review - reminder to review

<jamesn> https://github.com/w3c/aria/discussions/1850

<sarah_higley> jamesn: reminder to review the ACT rules, we have a github discussion that I should've put the link to

<sarah_higley> jamesn: we don't have a great number of people who have reviewed things yet

<sarah_higley> jamesn: some of the things I thought were problems weren't initially, but weren't

<sarah_higley> scottono: it was the ACT review that made me open up the issue on rowindex

<sarah_higley> jamesn: but if they've done a rule, it's something that's specified, so they've done their job right

<sarah_higley> scottono: yeah, exactly, if there are rules built around this, we should know what its purpose is

AccName Role Traversal Proposal - any updates?

<sarah_higley> jamesn: I want to know where we are on this

<sarah_higley> jamesn: I don't know if anyone on the meeting can give any details

<sarah_higley> scottono: Brian kicked it over to James Teh

<sarah_higley> jamesn: someone, probably me, should ping James Teh to see where we are on it, since it seems to have stalled

<sarah_higley> jamesn: personally I'm just in favor of writing in the spec whatever Chrome's doing, but I don't think Brian agrees with me on that

Better aria-expanded defaults for combobox

<sarah_higley> Matt_King: I don't want to make any changes to aria-expanded on the combobox. I want to make changes to aria-haspopup, but not aria-expanded. I think since that was Nov 3rd, and it's December Something, if you want to do the honors of closing the issue based on my comments and if Wilco wants to reopen it he could, does that seem reasonable?

<sarah_higley> jamesn: I just pinged Wilco to see if he wants to respond, and I'll close it in the new year

<sarah_higley> Matt_King: people can always reopen issues after you close them

[aria-haspopup at button should not change role]( https://github.com/w3c/core-aam/issues/51 & -> https://github.com/w3c/core-aam/pull/153 https://github.com/w3c/core-aam/pull/153 )

<sarah_higley> jamesn: they have pushed a change to CHrome to expose aria-haspopup=dialog as a regular dialog

<sarah_higley> Matt_King: our plan, that scott and I came up with, was to deprecate aria-haspopup for everything but true, men, and false

<sarah_higley> scottono: I still think that's a pathway forward. We've often had arguments about exposing the element as the popup instead of the element triggering it

<sarah_higley> scottono: I appreciate that the mapping change happened because if we deprecate it that's what we want to happen

<sarah_higley> Matt_King: I think this is a positive change because it moves in the direction of deprecation

<sarah_higley> jamesn: the whole deprecating aria-haspopup values complete would mean that anyone who wants to try to convey that a button does launch something other than a menu wouldn't be able to do so

<sarah_higley> Matt_King: we had a pretty detailed discussion on that, and I think we were all aligned here that having a button tell you that it's going to open a thing created more noise, pollution, and problems than value

<sarah_higley> jamesn: I'm slightly surprised by that, because Apple does say that something launches a popup, right?

<sarah_higley> general 🗣️🌶️

<sarah_higley> Matt_King: I think we had already gained consensus in the discussion, but if people want to object to the PR, they can object

<sarah_higley> jamesn: should we just go forward with the change based on what Chrome is doing? Or should we go further?

<sarah_higley> jamesn: the draft PR I created is that anything other than menu or true doesn't change it

<sarah_higley> sarah_higley: I'm in favor of that

<sarah_higley> scottono: practically I think it's fine Chrome implemented what they did, but I think we should go the extra step and remove everything else

<sarah_higley> Matt_King: I think we should have an extra role for menubutton

<sarah_higley> jamesn: I don't think we have that in every api, right?

<sarah_higley> Matt_King: do we not? I thought we did, I could be wrong

<sarah_higley> jamesn: I guess we could do something, it's the same thing

<sarah_higley> jamesn: I'm going to change this PR from a draft to something more formal

<sarah_higley> jamesn: and then if anyone wants to review that they can do so

<jamesn> https://github.com/w3c/core-aam/pull/153

<sarah_higley> jamesn: Didn't notice https://github.com/w3c/core-aam/pull/86/, I'll compare and close mine

1.3 blocking issues agendabot]

<sarah_higley> jamesn: where are we on the one that solves half of these?