Popover invoker example shouldn't have aria-haspopup

[mfreed7]

It was pointed out (@jakearchibald @aleventhal) that in this example:

https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute:~:text=button%20popovertarget%3Dmenu%20aria%2Dhaspopup%3Dmenu

the button with popovertarget also has aria-haspopup, but that's not right. Elements with popovertarget should automatically get aria-expanded via the UA, but shouldn't need or want to manually add aria-haspopup. Generally, using declarative popover triggering should be accessible by default, so no manual ARIA should be required in the base case. If folks agree, we should remove aria-haspopup from that example.

[josepharhar]

@scottaohara

[scottaohara]

that's true that the aria-expanded state is provided by the popovertarget attribute by default, but this example was provided as an instance where aria-haspopup would actually be expected to further change the semantics of this button to specifically be a menu button, since it opens a role=menu component.

So this is not a bug/incorrect, but maybe this could be more clear in why this example uses the attribute but, for instance, the previous example which opens a popover of a list of sub-navigation links does not use aria-haspopup.

[jakearchibald]

but this example was provided as an instance where aria-haspopup would actually be expected to further change the semantics of this button to specifically be a menu button, since it opens a role=menu component.

Why can't the UA infer that from the relationship that already exists between the button and the popover?

[scottaohara]

I'm not sure I understand the scope of your question?

Is this just down to a simple misunderstanding that one thinks aria-haspopup would be an expected relationship at all times - which is not true and why it was purposefully not included in the popover mappings - and is only useful in this one use case.

Or is this a question that requires a further explanation/understanding of what ARIA does / doesn't do in the context of HTML?

[jakearchibald]

It could be a misunderstanding.

You said:

this example was provided as an instance where aria-haspopup would actually be expected to further change the semantics of this button to specifically be a menu button, since it opens a role=menu component.

Which I understood as: This element should have aria-haspopup because it 'opens' a component with role=menu.

However, due to the popovertarget attribute on the button, the UA already knows that this button 'opens' a component with role=menu.

Since the reasons given for adding aria-haspopup can already be inferred from the content, it made me wonder why the author needed to provide these details twice.

It felt to me like how you don't need to give an <input> an aria-labelledby if a <label for> already provides that semantic connection. It feels like a similar semantic connection already exists in the example, but there's probably something I'm missing, and I'm keen to discover what it is 😄

[keithamus]

role=menu might not be on the same element as the popover, and instead might be a descendant, given the required constraints on what children are allowed.

[jakearchibald]

We're discussing this example where the role is on the same element as the popover.

[keithamus]

My comment was more generally directed at OP which states:

but shouldn't need or want to manually add aria-haspopup

Inferring seems sensible to me but I also felt it necessary to call out that the association isn’t always straightforward.

[jakearchibald]

To clarify, this issue is about this specific example in the HTML spec. I don't think anyone's suggesting that particular aria attributes are redundant in all imaginable cases.

[scottaohara]

yes, a misunderstanding.

Which I understood as: This element should have aria-haspopup because it 'opens' a component with role=menu.

maybe a better word choice for me would have been "controls". The open/close state is already handled by the button/popover association - so this was not really the point of the attribute. Rather, this is some rather annoying legacy baggage to ARIA where a "menu button" can only be defined by use of aria-haspopup and not by, for instance, adding a role=menubutton to the button element. If that role were available, then there would have been no need to use aria-haspopup.

However, due to the popovertarget attribute on the button, the UA already knows that this button 'opens' a component with role=menu.

In this example, sure. But not per @keithamus's reasonable alternate example. Nor would this association be possible if the popover was dynamically (in full or partially) created only when needed.

It felt to me like how you don't need to give an <input> an aria-labelled if a <label for> already provides that semantic connection.

Understand the comparison you're trying to make, but it's a bit off per what you were initially asking about why couldn't the UA just know to make the association based on the role=menu provided to the popover. And that's where a fundamental fact of ARIA comes into play, in that it does not change UA behavior, by design.

I don't think anyone's suggesting that particular aria attributes are redundant in all imaginable cases.

and circling back to how i started this response, this is a misunderstanding. this is not a redundancy.

[scottaohara]

the problem i see here is that this is a correct markup example for how someone would need to create a popover role=menu, and I could add more details to the example to get into the whys of this... but then I would be explaining ARIA concepts in the HTML spec, and I'm not sure how far one should lean into outlining ARIA concepts in a spec not about ARIA

[jakearchibald]

However, due to the popovertarget attribute on the button, the UA already knows that this button 'opens' a component with role=menu.

In this example, sure. But not per @keithamus's reasonable alternate example. Nor would this association be possible if the popover was dynamically (in full or partially) created only when needed.

Can we stick to the example in question? I'm finding it hard to figure out which statements are referring to the example linked in the OP, and which statements related to other imagined examples.

In the specific example, could the UA infer that the button 'controls'/'opens'/has-a-popup of type 'menu', given:

• The element is a button
• The element has a popovertarget
• The element referenced by the popovertarget has role=menu

[scottaohara]

outside of that one paragraph, everything i've mentioned is in context of the example in question. so, yes. i did stick to the example in question.

[jakearchibald]

If you can help me understand, I can help edit the example and surrounding text so others don't have the same misunderstanding.

[scottaohara]

i'd be happy to, but maybe this would be something we need to talk out? i've already answered what you asked, so i'm not quite sure where the disconnect remains?

[jakearchibald]

Happy to jump on a call or something, but it'd be helpful to get a clear answer to the second part of #9153 (comment):

In the specific example, could the UA infer that the button 'controls'/'opens'/has-a-popup of type 'menu', given:

• The element is a button
• The element has a popovertarget
• The element referenced by the popovertarget has role=menu

And if the answer is 'no', what ambiguity exists that needs clarified by aria?

[scottaohara]

the answer is no. and per my previous response

And that's where a fundamental fact of ARIA comes into play, in that it does not change UA behavior, by design.

this is directly related to this issue #9110, and why role=button wouldn't be a way to allow the element to invoke a popover

[jakearchibald]

I don't think I'm suggesting any UA behaviour change here, other than accessibility tree details, which ARIA absolutely does influence.

[jakearchibald]

this is directly related to this issue #9110, and why role=button wouldn't be a way to allow the element to invoke a popover

I don't see the relation there. That's suggesting a change to click semantics. I'm only suggesting the UA exposes information to the a11y tree based on content.

[scottaohara]

you may not realize it, but you actually would be suggesting behavioral change. a menubutton is treated differently than a standard button to AT. And if the UA automatically makes that change for this specific instance, it likely should continue down the cascade of additional functional changes that would be expected for a menu/menu button pattern. And if you do that, well then why not start making other changes automatically, e.g., the above linked issue? but then, you may also start introducing changes that the author doesn't actually want. it's messy.

[jakearchibald]

So:

• ARIA changes UA behaviour in terms of what ATs see.
• Other document state can change UA behaviour in terms of what ATs see (<button> vs <div>).
• There is some interaction between the two, as document state can take priority of ARIA, and ARIA state can take priority over other document state, depending on the state.

Am I right that the 'violation' you see here is that the UA would infer aria-haspopup-like semantics based on the role of an associated element? And this interaction between non-ARIA (popovertarget) and ARIA (role) would, via slippery-slope reasoning, cause the whole house of cards to tumble?

I think this is different from #9110 because the behaviour I'm suggesting here remains in AT space. It isn't changing non-AT behaviour.

My desire here is for pages to be as accessible as possible without developers having to re-state what is already stated in the DOM.

If the author has told the UA that a thing is a button (via <button>), and it controls/opens/has-a-popup (via popovertarget) something that is a menu (the target has role=menu), then it seems very reasonable that the UA tells the AT that the thing is a menubutton. That seems useful to authors and AT users.

[scottaohara]

I think this is different from #9110 because the behaviour I'm suggesting here remains in AT space. It isn't changing non-AT behaviour.

the reason they're related is because while what you are suggesting is just changing the semantics in the AT space, it doesn't get into the expectation of what other functional changes would be associated with those changes.

Again, happy to jump on a call to discuss this further, but I think we're going to keep going in circles otherwise.

[jakearchibald]

I feel like I'm struggling to get straight answers in one or two places here, which may be why it feels like a circle to you. I'd like to try one more time here, as it's documented for others.

For example:

Am I right that the 'violation' you see here is that the UA would infer aria-haspopup-like semantics based on the role of an associated element?

Am I right there? I'd like a direct answer to this. I was seeking clarity, and you've suggested you know the answer here.

the reason they're related is because while what you are suggesting is just changing the semantics in the AT space, it doesn't get into the expectation of what other functional changes would be associated with those changes

Can you detail those functional changes?

I feel we're from different schools of communication here. The situation we have here is either an example that creates confusion through lack of data, or an implementation that could be improved. My aim is to discover which of those problems we have, and understand it to the degree where I can fix it.

If you have that information, I'd love to hear it. If you don't feel you understand the problem enough to provide that information, it would be good to know that too, because I can stop bothering you and find someone with the relevant knowledge.

[scottaohara]

i agree that we seem to have two different communication styles / expectations of what should be sufficient answers. I'm not at all trying to be dodgy with you in my responses, but it's apparent that you seem to think otherwise. anyway...

Am I right there? I'd like a direct answer to this. I was seeking clarity, and you've suggested you know the answer here.

partially yes. i wouldn't say it's a violation, but it would be a change that would be highly reliant on the setup of the popover, which is why i know you keep wanting to have this scoped to just the example in the html spec, but the additional examples that Keith/I alluded to need to be considered as well. If the nuance of why this is needed is too much for devs to grock, then they sure as heck aren't going to understand why they'd need to do add the attribute sometimes but not others, based on their markup choices.

Can you detail those functional changes?

The primary functional change is that for a majority menu patterns focus automatically needs to move to the menu popup when invoked. And as I just briefly talked to Aaron Leventhal about this over the phone, he agreed that we would not want to change focus behavior based on ARIA semantics being changed. So, we're at an impasse of where the UA would be "sometimes" - per the above point - providing modified ARIA semantics for a situation the UA could infer, but not necessarily the modified behavior associated with that change in ARIA semantics. But let's say the decision was made to make that functional change in this one instance. Well, now what about the additional keyboard navigation behavior associated with going through the menuitems? Why wouldn't the UA do that automatically? It can snowball from there. For instance, would this decision then leak out to other HTML elements? e.g., if i were to do the following:

<details>
  <summary>...</summary>
  <div role=menu>...</div>
</details>

rhetorical: should that pattern not also automagically know that the summary should be exposed as a menubutton?

There'd then also be additional and more complex popover patterns to take into account. E.g.,

<button popovertarget=f>...</button>
<div role=listbox popover id=f>
  ...
</div>

There's a lot to unpack from what could automatically happen there, and it too would have more than just ARIA semantics that need to be conveyed, but a decision tree of varying keyboard/focus behaviors to go along with it, which would then also need to be contingent on the children of that listbox and if the author strayed from the currently allowed children of that element - e.g., if they included other non-option elements that would then require further UA modifications or potential repairs.

to be clear (i hope), these are all conversations that could be had. The relationship between ARIA and HTML could be revisited and rediscussed. But, we are also trying to keep this limited to just the example mentioned in the HTML spec. I obviously can't effectively do that when what is being suggested goes beyond that scope.

edit:

My desire here is for pages to be as accessible as possible without developers having to re-state what is already stated in the DOM.

I missed this from a previous message, but as an FYI, if popover attributes were not being used, the markup a developer would have to write for this now would be:

<button aria-haspopup=menu|rue arie-expanded=true|false>...</button>
<div role=menu>...</div>

so to your point, if a developer had to re-declare aria-expanded then i would be agreeing with you.

[keithamus]

Is there existing precedent for an attribute which only changes data in the accessibility tree (ie role/aria-*) to establish a relationship in the DOM tree? Unless I’m mistaken role is constrained to the accessibility tree, and has no effects on the DOM tree. Having popover invokers check the role of the popover changes this constraint.

The input/label example is different because that’s a relationship of two DOM nodes causing a change to the accessibility tree, not a DOM node and an attribute reserved for a11y purposes.

Part of me wonders if this is an opportunity to revive <menu>- at the risk of digressing from the core issue of “is this example correct”. Having a <menu> element which actually represents a role, and having the invoker of a <menu popover> change the AT might be an avenue worth exploring?

[scottaohara]

i'm afraid the ship may have sailed on <menu> at this point, since that's been relegated back to being another type of 'list' again. Re-introducing ARIA menu behavior at this point could potentially break some current usage of the menu element... but maybe there's a way to make such a change limited to if the menu element also has a popover attribute.... probably worth another issue though?

[jakearchibald]

i know you keep wanting to have this scoped to just the example in the html spec, but the additional examples that Keith/I alluded to need to be considered as well. If the nuance of why this is needed is too much for devs to grock, then they sure as heck aren't going to understand why they'd need to do add the attribute sometimes but not others, based on their markup choices.

I'm not sure about this. Developers seem to know that <label for> only builds a semantic relationship with the input if the for points at the input, not a container of the input.

The primary functional change is that for a majority menu patterns focus automatically needs to move to the menu popup when invoked. And as I just briefly talked to Aaron Leventhal about this over the phone, he agreed that we would not want to change focus behavior based on ARIA semantics being changed.

I can't repeat this enough: I'm not suggesting ARIA attributes should change things like focus. Popovers already have focus behaviours, and the example we're talking about already makes use of them.

Well, now what about the additional keyboard navigation behavior associated with going through the menuitems? Why wouldn't the UA do that automatically?

I wouldn't be against a browser feature that provides this functionality, but again, I don't think it should be inferred from ARIA.

For instance, would this decision then leak out to other HTML elements? e.g., if i were to do the following:

<details>
  <summary>...</summary>
  <div role=menu>...</div>
</details>

rhetorical: should that pattern not also automagically know that the summary should be exposed as a menubutton?

Would that be a bad thing? As in, would it be worse than how browsers currently interpret that DOM?

If I understand what you're saying, I get it, there are lots of interactions developers need to build to make certain components accessible, and it'd be great if HTML could provide them, and I agree that ARIA shouldn't provide them. I hope OpenUI continues to push on this.

In this case I'm simply suggesting that an ARIA attribute shouldn't be required if the need for that ARIA attribute can be inferred from other semantics, just as <button> doesn't need to be given role=button.

I feel this wouldn't be getting push-back if it didn't cross this conceptual ARIA barrier (that's fun to say), which is why we should be questioning whether that barrier is valid in this case, given the result exists purely in AT space.

[jakearchibald]

@keithamus

Is there existing precedent for an attribute which only changes data in the accessibility tree (ie role/aria-*) to establish a relationship in the DOM tree? Unless I’m mistaken role is constrained to the accessibility tree, and has no effects on the DOM tree. Having popover invokers check the role of the popover changes this constraint.

I mean… role is visible as an attribute in the DOM tree. From what I've understood from this thread:

• 😀 AT tree influenced by HTML attributes on two elements.
• 😀 AT tree influenced by ARIA attributes on two elements.
• 😀 AT tree influenced by an ARIA attribute on one element, and an HTML attribute on another (ARIA attributes often refer to the id attribute of another element, and id is an HTML attribute).
• 😱😱😱 AT tree influenced by an HTML attribute on one element (popovertarget), and an ARIA attribute on another (role).

And I'm not sure the 'constraint' makes sense.

[scottaohara]

I can't repeat this enough: I'm not suggesting ARIA attributes should change things like focus...

I know you keep saying that, but that's the problem, it's at odds with your proposal. If the UA will automatically change an element's role / a11y properties to something that should change focus / should come with implicit functionality, but it doesn't provide that functionality, then that'd be broken.

Developers seem to know that <label for> only builds a semantic relationship with the input if the for points at the input, not a container of the input.

do i have some code to show you sometime :)

[jakearchibald]

I don't feel it's at odds. Popovers already have focus behaviours. I guess our disagreement here is: I feel that an incremental improvement that removes redundancy is valuable, whereas you insist on a kitchen sink approach?

[scottaohara]

you think i'm insisting that? hmm.

[jakearchibald]

I thought that was the point you were making?

if the UA automatically makes that change for this specific instance, it likely should continue down the cascade of additional functional changes that would be expected for a menu/menu button pattern. And if you do that, well then why not start making other changes automatically

other functional changes would be associated with those changes.

Well, now what about the additional keyboard navigation behavior associated with going through the menuitems?

It feels like you're saying if we remove redundancy in this AT space, we'd simply have to make behavioural changes too. But I'm not seeing good evidence for that.

You bring up focus, but popover already has focus behaviours, so that wouldn't need to be added.

The keyboard interaction for menu items would still need to be added by the developer, and I hope this is something that OpenUI or some other group makes much easier than it is now. But I don't agree that it would need to be done along with this particular removal of redundancy that stays within AT space.

[scottaohara]

so Jake and I just hashed out a lot of this via a phone call. sorry not sorry we took this offline, but we needed to do this to better understand where each of us were coming from.

We do now agree there is a level of redundancy that an author would need to do not only markup a popover as a menu, but also indicate this via the button element with aria-haspopup. We did also come to an understanding that this is unfortunately a bit of redundancy that comes with creating custom components using ARIA. Where as had there been an actual HTML component that provided the necessary semantics and behaviors of a role=menu, then there would not have been an expectation for an author to need to set aria-haspopup on the button. Because, the UA would have been able to make this association, and thus update the button's role, but the UA could then also deliver on the functionality that it would have been promising to AT users, by exposing that role.

With that said, we saw two pathways forward here:

1. add a note to the example to indicate that as this is a custom component build using ARIA, even though some of these attributes may seem redundant, it is the author's responsibility to add the ARIA properties and provide the necessary functionality that goes along with them.
2. Remove the attribute from the example so as to not confuse authors - which is fair, this stuff is confusing - but maybe also add in a note indicating that one might consider also using aria-haspopup on the button, and then maybe linking to information about that attribute? This last bit I did not discuss with Jake specifically, so please call out if you think it's a bad idea or not. Just thinking of the a11y-focused people who could come along, see the example in the HTML spec and be like "well it's missing the aria-haspopup attribute" and then we have a whole other issue filed about that purposeful omission.

@jakearchibald please feel free to add in anything that I may have forgotten or glossed over. thanks

[jakearchibald]

That all seems right to me. I think which option is best comes down to how useful aria-haspopup=menu is, or how harmful it would be to omit it. I think you suggested it was kinda on the useless side?

For option 1, I think that we should acknowledge that the redundancy suuuuucks, and that hopefully, in future, it could be replaced by a proper HTML element that has all the behaviours and semantics.

[annevk]

Why isn't a button with popovertarget enough of a semantic signifier to deserve implicit aria-haspopup=menu semantics?

Until we have custom element buttons you need to use showPopover() on some kind of custom role=button element and then you'd need to use aria-haspopup=menu explicitly I guess.

[annevk]

cc @whatwg/a11y

[patrickhlauke]

The popovertarget could open something other than strictly a role="menu", unless I'm misunderstanding? it could effectively just act as a disclosure widget trigger that opens an arbitrary panel (rather than a strictly defined "menu"). for that reason, I don't think it should automagically be assumed that popovertarget means "so implicitly it needs to have aria-haspopup="menu"". at a stretch, it could see the argument for a more generic aria-haspopup="true", but then the more generic value here would not be great when it is a more specific case like a menu that is opened...so it may well be that there should not be any magic/implicit mapping here, and it's left to the author

incidentally, just looking at https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute:~:text=button%20popovertarget%3Dmenu%20aria%2Dhaspopup%3Dmenu can I suggest that the id of what gets popped up is changed from id="menu" to ... something else? it makes it confusing when you see popovertarget=menu aria-haspopup=menu in that demo and "menu" there are two different things (an idref in one case, and a specific named value in the other)

[hidde]

Reading this issue, I understand the presence of aria-haspopup in the example in the spec text.

I do worry that it may sit in the way of developer's easily understanding what is going on. Especially given that ARIA is outside of HTML, and the string “haspopup” includes the word “popup”, while you're trying to define an attribute named “popover”. Imho this adds mental overhead for web developers, which could lead directly to wrong usage and, with that, potentially bad / inaccessible end-user experience.

The popovertarget could open something other than strictly a role="menu", unless I'm misunderstanding?

Yes. As I understand it, it can open elements with a number of roles (including listbox, menu, dialog and more), as well as elements that don't have a role at all.

I am probably misunderstanding something, but I wonder… if we're expecting developers to use roles to indicate the semantics of their popover, couldn't that value be used to automatically set a aria-haspopup for any role that is the same as a valid aria-haspopup value?

For example:

// The popover is a menu, maybe the browser can safely automatically add aria-haspopup=menu?
<button popovertarget="myMenu">Open menu</button>
<div popover role="menu" id="myMenu" >…</div>

// The popover is a listbox, maybe the browser can safely automatically add aria-haspopup=listbox?
<button popovertarget="myListbox">Open listbox</button>
<div popover role="listbox" id="myListbox" >…</div>

// The popover is a dialog, maybe the browser can safely automatically add aria-haspopup=dialog?
<button popovertarget="myDialog">Open dialog</button>
<dialog popover id="myDialog" >…</dialog>

// The popover has no semantics, maybe the browser adds no aria-haspopup 
<button popovertarget="myPopover">Open popover</button>
<div id="myPopover">…</div>

(Was thinking it could default to dialog, but defaulting to no aria-haspopup is probably safest as there are cases like tooltips that are explicitly (but non-normatively) not dialogs)

Or would the above example be very unhelpful given there are, in addition to this aria-haspopup relationship, some complexities / user expectations that come along with the semantics, like those @scottaohara mentioned above? Quoting Scott from above:

a decision tree of varying keyboard/focus behaviors to go along with it, which would then also need to be contingent on the children of that listbox and if the author strayed from the currently allowed children of that element - e.g., if they included other non-option elements that would then require further UA modifications or potential repairs.

Either way, one thing this shows is that a lot depends on web developers making the right choice for their thing between a lot of different but slightly similar semantics. I would love such examples to exist somewhere (maybe even in the spec, and maybe with concrete examples of what goes in the actual popover, so that web developers are more likely to choose the most appropriate).

[scottaohara]

As mentioned in my last comment, I’ll update the example. I’ve been on vacation so I haven’t gotten to it yet. I will next week.

[hidde]

Sorry, didn't mean to derail that course of action with a whole new suggestion, @scottaohara. When you get to it, I would happily volunteer to help review the example if an extra pair of eyes is useful.