popovertargetaction=show/hide when popover is already shown or hidden

[scottaohara]

Thoughts on whether this should be exposed as 'disabled' in the accessibility API - since the button won't actually do anything if the popover is in the state that matches the action value.

[YummyBacon5]

I think that it should not have disabled. Since wouldn't the state of if the popover's shown or not be conveyed through aria-expanded? Also, if an author has their own aria-disabled on a popovertargetaction button, then this may mess with that.

---

But on a slightly different topic, if there's a popovertarget button as a child of the same already shown popover, then I think this should be aria-expanded=undefined. Since obviously a popover is already shown if the user is on a close control inside it.

To better understand what I mean:

<div id="p" popover> <!--Popover is shown-->

    <button popovertarget="p">Close</button>
    <button popovertarget="p" popovertargetaction="toggle">Close</button>
    <button popovertarget="p" popovertargetaction="hide">Close</button>
    <!--These all should have `aria-expanded=undefined`-->
</div>

[cookiecrook]

Sounds like this is identical in functionality to <button>foo</button>… It's not disabled, just not doing anything.

[smhigley]

A few real-world use cases that seem like they would be harmed by this come to mind:

• a show button that shows a popover when hovered (hint), but it's still possible to click the button after the popup is shown, and that pins the popover and moves focus within it.
• A button that opens a non-modal popover pane, where subsequent clicks to the button move focus to the popover, even if they do not change the popover visibility
• A hint tooltip with a trigger that only shows (e.g. because the author is handling the hide logic with custom script). The tooltip trigger also has a primary action

I could be misunderstanding how to use popover=hint vs. popovertargetaction, but I can definitely see authors creating an expand-popover target that also has an additional action be something that is more than an edge case.

I'm also generally leery of browsers magically marking a trigger semantically disabled while the author still thinks the trigger is enabled, and while the trigger is enabled for anyone not using a screen reader. I'd rather take the stance that authors are responsible for deciding whether the element is enabled or disabled equally for everyone.

[scottaohara]

unless anyone has any compelling use cases that couldn't arguably be redesigned to mitigate issues of buttons that don't 'do anything', it seems like the answer from today's call was "no" don't automatically do this.

I think from @YummyBacon5's example, the only thing not covered in the current PR (#481) is to potentially set the close 'toggle' button that is a descendant of the parent popover should instead have aria-expanded=undefined as well.

[spectranaut]

Minutes for today's meeting: https://www.w3.org/2023/10/12-aria-minutes.html#t05