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 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() 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 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 |
08:56 | <Noam Rosenthal> | keithamus: on remove, the focus is simply lost. Frameworks today sometimes compensate by calling focus programatically |
08:56 | <keithamus> |
.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 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 |
08:59 | <Noam Rosenthal> | That makes sense. I wonder if the move operations should cause explicit announcements in AT? |
08:59 | <keithamus> | That makes sense. I wonder if the move operations should cause explicit announcements in AT? |
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 |