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 2713 needs reviews, author not present, but its editorial
Github 2712, another editorial in need of a quick review
Github 2706, simple change to HTML AAM to make a whitespace only alt strings considered empty
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Discuss ARIA 1.3 publishing timeline
spectranaut_: we are working towards publishing ARIA 1.3, so if anyone wants something to be added to that public working draft, and they are willing to champion it, and there is a chance to get implementations, add the aria 1.3 tag to it on Github so we can work on it in the next new months
aria-actions: handling focus when actions are synthetically triggered
<jamesn> w3c/
Matt_King: I just added a comment to it that should help move the discussion forward (see link above)
Matt_King: The point of the comment is at the end in the three questions it is asking. I give an example of one of the potential usages being developed for the APG (though the task force is discussing making changes to that change, we may branch the PR so the link to this example is stable). I present the use case three scenarios of different ways a user would interact with it.
Matt_King: JAWs currently doesn't do anything because of the blockers in this issue. The Expectations column in each scenario gives what the expected outcome is in the UI, not what the browser is expected to do.
Matt_King: I think that we need to support these scenarios, and I'm not sure that the suggested solution that Sarah presented would solve the screenreader case completely.
jcraig: Question: these are speculative expectations?
Matt_King: Only for the screen reader. For all the others it is how the example currently behaves.
jcraig: Screenreader here is a stand in for many other ATs?
Matt_King: yes
jcraig: When focus is mentioned here it is unclear if it is referring to AT focus or keyboard focus?
Matt_King: I tried to be careful about that and may need to add some words to make it 100% clear when each focus is referred to. I can correct that.
<np-at> In this example, the browser focus remains on the listbox, aria-activedescendant is what is shifting, correct?
jcraig: We may need to move the example so people without admin privileges can play with it.
jcraig: If the author receives the click and then calls focus on something else, then we do want to follow that particular notification?
Matt_King: I wanted to add another scenario for completeness where it is a destructive action and focus has to move. That may add some edge cases that would be useful to document.
jcraig: It isn't just destructive actions where the author moving focus can change things?
Matt_King: True
jcraig: Do we want to move the table into the description at the top so it's easier for people to see when they first come to it.
Matt_King: That would be cleaner so it isn't lost as discussion continues in future comments.
np-at: For the destructive actions, is that up to the author to indicate? There are occasions where depending on the author' intent it may make sense to revert focus back to something else. It seems like it should be left up to the author's discretion for that?
Matt_King: My understanding is that it is completely up to the author to manage focus.
<Zakim> jcraig, you wanted to reply to np-at
jcraig: My suggestion included that we don't ever prevent authors from having control over where focus goes.
jcraig: That is a goal for what we want to be achievable, but if the action does something behind the scenes, and the triggering element is still in the view, focus shouldn't move from where the user already is even though the button being clicked via the action is elsewhere.
Matt_King: We can test out this scenario with the different options and add other test scenarios if needed. My suggestion is that for each option we consider, write down for each scenario what specifically isn't possible, thus why we would rule it out.
Matt_King: I will move the table into the first comment, and may add a destructive scenario if needed, but maybe we should wait since it may add too much complexity.
<np-at> the destructive behavior should fall under the existing focus management guidelines
jcraig: The reason why I disagree with that is that Matt's examples write test expectations for when focus shouldn't move as part of this. So in the cases where it absolutely should move, we should document that so we are sure that any implementations know they are expected to continue to follow other standard focus handling procedures.
jcraig: Keyboard focus shouldn't do anything new, but we are discussion management of AT focus in the scenarios Matt presented as that may have some different behaviors than what we currently do.
jcraig: example, in gmail if you hover over the row you get buttons to reply, forward, delete, etc. If the user hits an action on the star button, if gmail hadn't handled standard keyboard focus, it would move onto the star but AT focus remains on the row.
feat: aria-actions addition to the ARIA spec
Matt_King: The opening text mentions the close button on a dialog. I had questions related to our 2024 TPAC discussion on inheritance.
Matt_King: On Sept 11th I made two statements about inheritance and if they are accurate it would drive some changes in the text.
<jamesn> w3c/
jamesn: Sarah did thumbs up that comment
jcraig: I remember asking some engineers about this but the answer was not definitive so I will go back and check into that again.
jamesn: It sounds like a reasonable ask for the implementors, but this is already a complicated thing, so asking people to add properties for this seems like a reasonable ask.
Matt_King: The TPAC 2024 comments on this were pretty rich, but I was trying to boil it down. We may need to scrutinize the current text in relation to this and maybe scratch the dialog close button as a primary use case of actions.
jcraig: I don't want us to pin us in the corner with this since has been deployed to dozens of ATs and it could cause some complexity, and we came up with some author situations where it may not be desirable.
Matt_King: I
Matt_King: I am pretty sure this wouldn't conflict with any current implementations, but there are some examples where you could end up with issues with nesting elements inheriting, but that could be an author issue.
jcraig: I don't think we need to work out the specifics today.
Expose implicit ARIA semantics (browser-defaults and ElementInternals)
jamesn: I don't think there is too much for us to do with this today but I don't want us to lose this. We have to work out how to resolve it but I have no idea how.
jamesn: Last comment is worth reading. Keeping this on the agenda because it is so important to make sure people can continue to do automated testing. If people can't test as much as they used to be able to because people lack the experts to work around the automation limitations of this new technology, that is a step backwards for accessibility.
benbeaudry: Based on previous discussions with this group I am getting the sense that. With Proposal I've been hearing positive feedback. I am going to bring it up with another working group to make sure they know we don't want to break accessibility. Is there any pushback from this group on doing that?
jamesn: I would love you to "at" me in the issue so I can keep an eye on it.
Daniel Montalvo: me too
jcraig: Since this is happening as part of Elementinternals, that's where the discussion should be, in a separate thread. I'm also a little, not concerned, but thinking that the name shouldn't be "internals ARIA" since it may have other things that aren't ARIA that have to be added. People understand ARIA but may think it's a live update, not just a reflection of what's in the content attributes and DOM properties, not the live
accessibility tree.