Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: None of this we need to look at.
… 2824 dependabot
… editorial update taxonomy of states and properties
pkra: Easier reviews if someone wants to have a look
… Good to get an understanding of the spec
theo: I'll take a look
pkra: The next one is even easier, adding the synonymous
Theo: Happy to take a look at this one too
katez: I'll also take a look at this
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: 9 new issues
pkra: You can ignore the ifrst one
jamesn: Structured content for aria-notify
… This is from the i18n review
pkra: I tried to find the conversation where it was dec ided for the future
jamesn: We need to pull in the person working on aria-notify
<smockle> https://
sarah: Goughd and Jacque. Not sure how this owuld work
<smockle> w3c/
jamesn: Probably we can just put a note
pkra: Specific question is if we've considered structured content, and we have
Clay: Just dropped a couple links on irc for context, I'll put them in the issue
jamesn: Add specific language and direction metadata to aria-notify. Can I do the same thing with this Clay?
Clay: Will do
JamesN: Translatable attributes
Clay: This is not aria-notify specific
jamesn: We've looked at this before
… Would anyone want to take this on as a research for us to be able to put something in?
pkra: You can assign it to me
jamesn: Next is on the editors agenda
… Browser Testing and Tools WG have it in their charter but want to drop it because there hasn't been enough progress
Daniel: Editors draft uris is for editors too
jamesn: Mappings for row and gridcell elements with aria-checked
Theo: It's not clear how this would map in AX, current mapping using menuitemmarkchart, doesn't seem right for this, just wanted to make sure there's an appropriate mapping for it
jamesn: add value attribute as name source for input type=image
… Value is allowed in an input, seems like it should be
giacomo-petri: It's not
jamesn: Should weinclude something in the accname calculation that is not valid hTML?
<aardrian> No.
giacomo-petri: I believed it was. Since it's not, we should do something about it. Browsers are considering it to remediate author errors but that's not a reason for us to include it
Jamesn: I agree with that. Can you add a comment to the issue?
giacomo-petri: Yes
jamesn: aria-level relation with heading offset
… Good question
keithamus: I think this is already the case in engines, that's why we set it to level 9. If I recall, in Chrome, any values above9 get reset. Agree the spec should reflect reality
aardrian: Also platform related
jamesn: Does someone want to addd it as a comment?
aardrian: I can
keithamus: I can take that one as well
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: First one. I discovered that Jacque is not a WPT reviewer
… I asked Simont to add him to the reviewers lists
… Will do the same thing for the next issue
… Anybody on the Edge side
Theo: I didn't see this one, relates to something I need to do on my PR
jcraig: 68533. Cynthia reviewed itk, same issue
<jamesn> S/68533/60533/
jcraig: Candidate tests for the flat tree
Theo: Not urgent, if people wantto review that's fine
jcraig: 60503
… This seems like a great use of the new functionality.
… I'm reluctant to merge it given we don't have two "checks"
… Chrome and Safari don't havesupport for it yet, FireFox has a different result
… It's ont clear which is which
… I'd like to ask for the opinion of the group on whether we can just merge and assume this will work sometime in the future or wait until we have more validation
cyns: Isn't it what tentative is for?
jcraig: This is different. If all of them had a similar result that would mean that the method is implemented and that failure represents a real bug in the browser
qTheo: This one is specifically not passing even with the patch
… For Chrome Val was working on this, I didn't do anything forSafari
… Worth asking ourselves if this is the desired outcome
… Should we be checking things that are at the bleeding edge?
jcraig: If it has any support maybe. Some old ones threw a "spec ambiguous" result
… For this one I would expect testing the ones that pass too
… Then we would have a baseline pass. That would make me more comfortable s to what we are actually testing
jcraig: Thanks Theo for all your work
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: I propose not to plan any for now, it's the summer
… Are folks generally available next week for meetings knowing that the Friday is a US holiday?
aardrian: Out next week
jcraig: I'll be working
jamesn: We will probably still run the meeting
aria-actions: handling focus when actions are synthetically triggered
jamesn: Where are we?
jcraig: I think we are coming around to the fact that focus can be modified based on an AT trigger
… My reluctancy before is because a platform design principle disallows that
… But since we are asking for a different focus cascade would be one way to resolve it
… As long as we could obfuscate it, I think we would be comfortable
… You wouldn't be able to distinguish if that was triggered by agentic AI or other AT
Sarah: We've been talking to AT to see if AT could handle it
jcraig: We don't think focus bounce is the right way to do it, we should figure out a way in the user agent to prevent the focus cascade to happen
Sarah: Cool
Matt_King: FYI we justpublished a newrevised experimental example of a list box iwth actions that appear on hover or focus
… I see that the publication PR got merged before this meeting but I am not seeing the example there
Daniel: Let's giveit an hour or so and if not I'll ask Rémi
<Zakim> jcraig, you wanted to discuss explicit click-focus
jcraig: Next thing we discussed is that Safari has a default behavior that clicking some elements doesn't result on focusing
… Part of the reason for this is selection
… This is mac platform. Any other browsers don't align with this
… Synthesizing a clikc that would otherwise move focusc to something which would not otherwise be focusable may give us an opportunity to determine whether or not that functionality should override that of the browsers
… Authors could then choose
Matt_King: I can understand how that might be helpful, but generally speaking the use cases we have are ones where we want a person using the mouse to have the focus moved but not moved if the action is executed by a screen reader users
jcraig: I am not clear on those particular examples
… In these edge-caseexamples why wouldn't you want the screen reader behavior to be the same?
Matt_King: I wish we could use the example with voiceover on iOS
jcraig: There are advanced flags on iOS
jamesn: Would be good for you all to take this offline for better understanding
Matt_King: +1 for folks to get a stronger understanding about the differences
jcraig: I am having travel determining whatkindd of rule we could put in the browser for acknowleding this
… For delete you want focus to move elsewhere
jamesn: Still lot of todos and people need to talk to each other
… It is a small subset of the meeting who should talk and get to an agreement
Sarah: I'll talk to Jacque about having the browser handling this
jcraig: I think so,
Tyler: If AT does it there might be a tming issue when the AT get the notification the author has done something else
Allow aria-valuetext for use with combobox role
Matt_King: It looks like changes were made to valuetext but not to textbox
… This is still in the combo box section of the spec. We should change this
jamesn: Could you do that?
Matt_King: I could. One question though is how to avoid braking select-only combo boxes written with the current guidance
… Will we be adding another waay and puting a note or something?
jamesn: I was supposing that the value would remain the same unless the user changes it, then an algorythm would need to be put in place to support it
Matt_King: You wouldn't be able to determine this unless the valuetext contains the visible text or other information. Do we want to do something there to prevent problems?
aardrian: Jamie mentioned that too in the issue comment. If you have some ideas it might be worth jumping in.
Matt_King: I could make a PR against this PR
Matt_King: Github Suggestion works for single lines, difficult to do multiline
… I'll put a comment on the PR describing the proposed changes
9.3 Presentational Roles Conflict Resolution does not consider custom element use cases
jamesn: Does anyone want to take a look at this?
… There is other related issue
keithamus: They are different
keithamus: This one I think something Aaron was looking at. ARIA attributes in custom elements that can be forwarded, which is problematic because they might end up being announced
jamesn: If somebody explicit uses elementinternals with role other than none, it would allow those aria attributes but not expose them
… Is this implemented in Chrome?
keithamus: I remember Aaron working on it, not sure where he got to
keithamus: I can take this on
Explicit vs implicit roles for elementInternals
keithamus: We had a mistake in the minutes
… Not sure that the discussion was entirely clear. I think the conclusion was that element internals should override the attribute, which I think should not be the case, should be other way around
jamesn: Would that override if some explicitly sets the role?
keithamus: It should not
jamesn: But what if they set it up in the child?
keith: Terrible way of doing things
keithamus: There's more to unpack here. Maybe this is related to the other issue and we need more exploration to see if it's only related to none
… I'll take a look