Meeting minutes
New Issue Triage
jamesn: 6 new issues
… #2055
… need to wait until spectranaut is back, will agenda for later
… accname #205
jamesn: there’s a whitespace project in accname, including #83 which is applicable
jcraig: maybe the resolution here is to not test this particular case in WPT
BryanGaraventa: we agreed to change the spec and browsers already did that work speculatively
… so browsers are actually doing it correctly, but the spec hasn’t been updated yet
<jcraig> Bryan is correct about Chromium: https://
jamesn: this accname #168 issue sounds like what you’ve described, and it just hasn’t been merged
… so this PR needs to get resolved so we can merge it, then write some tests
jcraig: I’ll pull accname #205 back; BryanGaraventa is right about this
… and I’ll file a WebKit bug
BryanGaraventa: I’ll go back and look at accname #168
melsumner: I’ll help with that
jamesn: next issue, accname #204
jcraig: needs CSS spec update
jamesn: would anyone like to take this?
melsumner: I will
jamesn: next issue, accname #203
… anyone want to work on this?
… is it urgent?
jcraig: no, it can wait
… will tackle in October
jamesn: next issue, html-aam #505
scotto: encountered this when defining popover mappings
… popovertargetaction has toggle behavior
… should we let users know when a close button will actually do nothing?
jamesn: why does this close button even exist if the popover is already closed?
scotto: there could be times when you have both an open and a close button in the UI, as siblings in the primary document
jamesn: then one or the other should be disabled
MattKing: if you have two buttons, then you shouldn’t be using expanded/collapsed
sarah_h: I don’t think we should automatically disable them since it’s not intuitive for authors
… a good example is a button that always has show behavior — it would be weird to disable that when the popover is open
<Zakim> jcraig, you wanted to say this is identical in functionality in <button>foo</button> not disabled, just not doing anything.
MattKing: since this is just triage, we need to agenda it for next week
jcraig: I agree with sarah_h
jamesn: me too, now that I understand the example better
… will agenda for next week
… next issue, aria #2052
… scotto, will you own this?
scotto: we should agenda this too
jamesn: okay, will do
New PR Triage
jamesn: html-aam #504
scotto: I’d like jcraig’s review on this
jcraig: I will
jamesn: next PR, aria #2054
… I’ll add MattKing for review
CoryJoseph: I’ll review also
jamesn: next PR, aria #2053
… editorial change
… pkra has already reviewed it
… I think that’s enough
… if anyone else would like to review, please feel free, otherwise I’ll merge
WPT Open PRs
jamesn: WPT open PRs
… there are 11 here, jcraig — do any need attention?
jcraig: yes, we’re trying to figure out focus areas for Interop 2024 this week
jamesn: okay
… #42234
jcraig; every form element has an embedded control
… it’s a long one, but not difficult to review
jamesn: I’ll review this one
… next, #42203
jcraig: this is effectively editorial
… quick, easy review
… good first review
Rahim: I’ll review
jamesn: next, #42093
jcraig: we can pass, already approved
jamesn: next, #42013
Rahim: I’m still working on this
jamesn: next, #42011
jcraig: this is a manual test, leave for spectranaut
… ditto for #41522
… we’re good on all the rest
Seeking clarity on name property with div
jamesn: accname #202
… can we close this?
jcraig: assign it to me and I’ll close it after chewing on it some more
giacomo-petri_: as an author, I may want to use the title and let the browser use it as a “fallback”
MattKing: I think this is a case where accname should say title should *not* be a fallback for accname
… so authors can use it to be a mouse tooltip, but it wouldn’t be the accname
MattKing: we probably should also prohibit aria-describedby on a generic
jcraig: let’s file an issue on accname
… giacomo-petri_, would you?
giacomo-petri_: yes, I’ll file an issue
BryanGaraventa: should we have a deep dive?
<melsumner> I almost feel like we could just clarify as an editorial thing. WDYT?
jamesn: let’s discuss this after the issue is created
scotto: I also think there’s an html-aam issue here, I’ll file one
Consider allowing searchbox as a child of listbox / menu
jamesn: scotto?
scotto: we have common patterns where a button will invoke a popup, and that popup is a listbox but there’s a textbox at the top
… typeahead to filter the list of options
… per current allowance, I’d normally recommend that popup be a dialog
… and then associate the text input with the listbox
… we’re coming up with a new select element over in open UI, this being one of the use cases
… it would require the browser to juggle the DOM
… so I’ve wondered can we just allow the searchbox as a first child of listbox?
MattKing: I don’t get it — isn’t this just a combobox?
scotto: it’s not as simple as that
… I’m talking about the *button* that opens the popup, where the text field is inside the popup
MattKing: I’m talking about just the select
… I agree that the popup should be a dialog
… I’m just saying that the contents of the dialog; the combination of the textbox with listbox, *that* is just a combobox
scotto: yes, we could treat the original element as a plain button, but then if that dialog is being dynamically injected, how do we express the button?
Rahim: in terms of structure of this widget, does it make sense for the search to be outside the listbox?
… as a sibling?
scotto: per current rules, yes, it would be a sibling
<melsumner> FWIW, JS engineers in my world get this wrong ALL THE TIME
scotto: just trying to open the question of whether that’s necessary
… in my own experiments, it seemed that enclosing the text box in the listbox wasn’t a huge problem
… what do we gain by prohibiting it?
BryanGaraventa: I’m familiar with this kind of control in Firefox
… the issue I had was with virtual cursor context
… you can’t see that there *is* an input
… when I went looking for it, I had to turn off the virtual cursor and had to tab through instead
… irritating
… because a listbox is intended to be a one-line widget
jamesn: how do we move this forward?
… create some examples and see what actual problems we encounter if we were to pursue this?
sarah_h: I have an example of it in a menu
MattKing: fundamentally, it seems like an a11y tree issue
… text boxes and list boxes should stay separate
jamesn: path forward to prototype some cases?
BryanGaraventa: I can certainly test
sarah_h: I’ll make some examples
Monthly PR Triage - Will reserve at least last 15 mins for this
jamesn: need to get through some old PRs across all repos
… oldest first, from 2019
… accname #60
… this can be closed, right?
BryanGaraventa: yes
jamesn: next, accname #66
jcraig: there will be conflicts
jamesn: yes
jcraig: I think we should just use a standard HTML example
… I’ll take assignment of this PR
jamesn: who wants to review?
BryanGaraventa: me
jamesn: next, accname #90
… why hasn’t this been merged?
… looks like this can be merged by editors
jcraig: I’m suspicious of one change; I’ll add a comment
jamesn: next, aria #1413
… I’m just going to close this, there was never agreement
… and will leave the underlying issue open
jamesn: next, aria #1494
… I thought this was done?
… very simple change
… something to drive validators on
scotto: definitely remember talking about this, maybe we just never brought it back up for re-review
jamesn: did we handle this with an authors MUST NOT statement in section 9. Handling Author Errors?
… volunteers for review?
JaunitaGeorge: I’ll review
melsumner: I’ll also review
jamesn: next, html-aam #359
scotto: I’ve been requesting UIA help on this
… mappings for UIA don’t make sense
jamesn: will re-ping
jamesn: graphics-aria #9
… just needs to be merged — right, dmontalvo?
dmontalvo: yep, we can merge
jamesn: done, merged
jamesn: next, html-aam #395
scotto: this one goes along with a PR I just merged
… I need to check on this
… we have reviewers
… just need some double-checking
jamesn: next, html-aam #396
scotto: yep, I’ll take this