WHATWG on 2024-10-14

08:31	<quadristan>	Hello! I think i've spotted a typo in `nooopener-allow-popups`. there is an additional o in https://html.spec.whatwg.org/multipage/browsers.html#coop-noopener-allow-popups . I'm opening n MR to fix this
08:32	<smaug>	keithamus: Hmm, doesn't the step 4 assert in https://html.spec.whatwg.org/#show-popover fail if beforetoggle (once:true) listener doesn't call preventDefault() but calls showPopover()
08:33	<smaug>	(happened to read that algorithm while looking at the other relevant stuff)
08:49	<Noam Rosenthal>	keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard.
08:51	<Noam Rosenthal>	keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard. We did have an internal a11y review specifically for this, and there were no concerned raised. That's because elements can already stay in place and everything else move around them, and the developer can call `focus()` programatically anyway as well. So `moveBefore` doesn't add anything new here as long as we make sure the AT is up to date
08:52	<keithamus>	keithamus: Hmm, doesn't the step 4 assert in https://html.spec.whatwg.org/#show-popover fail if beforetoggle (once:true) listener doesn't call preventDefault() but calls showPopover() Step `9` prevents going further though right?
08:54	<smaug>	Ah
08:55	<keithamus>	keithamus: looping back on https://github.com/whatwg/html/issues/10666#issuecomment-2408260094 (keeping focus for moving elements during `moveBefore` from the last WHATNOT). You've raised concerns about a11y with focused elements. Is w3c/aria the right place to open an issue about this or somewhere else? https://www.w3.org/WAI/about/groups/ariawg/contribute/ is kinda confusing in that regard. if you've had an internal review and it was deemed okay then I won't raise any further objections. I'm not an expert by any means but it seemed perhaps not-ideal IMO to move focus, because - yes while the user retains focus - their position relative to the page may have moved which may be very confusing as the traverse onward. I think it is perhaps analogous to talk about `remove()` than to talk about `focus()`. If a developer calls `remove()` then browsers try to traverse the hole up to a nearest container to set the sequential focus start point, no? I'd perhaps offer that might be more preferable than moving their focus, because the position in the page hasn't change but there is also an acknowledgement that something on the page has changed.
08:56	<Noam Rosenthal>	keithamus: on remove, the focus is simply lost. Frameworks today sometimes compensate by calling `focus` programatically
08:56	<keithamus>	if you've had an internal review and it was deemed okay then I won't raise any further objections. I'm not an expert by any means but it seemed perhaps not-ideal IMO to move focus, because - yes while the user retains focus - their position relative to the page may have moved which may be very confusing as the traverse onward. I think it is perhaps analogous to talk about `remove()` than to talk about `focus()`. If a developer calls `remove()` then browsers try to traverse the hole up to a nearest container to set the sequential focus start point, no? I'd perhaps offer that might be more preferable than moving their focus, because the position in the page hasn't change but there is also an acknowledgement that something on the page has changed. IME the biggest pitfall and biggest source of complaints we have when building out accessible interfaces is the user getting no acknowledgement of the page changing. Calling `.focus()` is an acknowledgement (because AT potentially re-reads the content).
08:57	<Noam Rosenthal>	IME the biggest pitfall and biggest source of complaints we have when building out accessible interfaces is the user getting no acknowledgement of the page changing. Calling `.focus()` is an acknowledgement (because AT potentially re-reads the content). AT is a different story, we have to update AT after calling `moveBefore` to account for the focused element perhaps moving, or regardless because the tree could change in many ways when the DOM hierarchy is modified
08:58	<keithamus>	AT is a different story, we have to update AT after calling `moveBefore` to account for the focused element perhaps moving, or regardless because the tree could change in many ways when the DOM hierarchy is modified That makes sense. I wonder if the move operations should cause explicit announcements in AT?
08:59	<Noam Rosenthal>	That makes sense. I wonder if the move operations should cause explicit announcements in AT? They do in blink; Not sure how that translates to spec-land
08:59	<keithamus>	That makes sense. I wonder if the move operations should cause explicit announcements in AT? Though that might be too noisy. This is why I encouraged y'all reaching out to ARIA WG btw, I don't intend to throw spanners I am just unsure what should happen here and would rather hear from the experts.
09:00	<Noam Rosenthal>	oh you mean that the user will get notifications that something changed? I don't think sdo
09:00	<Noam Rosenthal>	You could be e.g. removing an intermediate layout container that has no content significance
09:01	<Noam Rosenthal>	(we've discussed this with our internal a11y experts as I said)
09:03	<keithamus>	You could be e.g. removing an intermediate layout container that has no content significance Yep, makes sense to me 👍️