Bring back support for aria-haspopup

See also #1736 as this is related to the Mentions plugin and the ARIA combobox widget.

I’ve read https://github.com/facebook/draft-js/commit/744e9b4eb4810797a93c66591fea6f9cac533b4b

Summary: aria-haspopup is used to indicate “popup button”; buttons that, when pressed, show a little menu of options. It’s not meant to indicate any element that has a dialog associated with it.

I must kindly disagree and kindly ask you to reconsider that change 🙂

Seems to me this change is not correct and a quick reading of the specifications can help understand. Please notice there are differences between ARIA 1.0 and ARIA 1.1. Thankfully, the ARIA Authoring Practices describe very well the implementation details. Probably the ARIA 1.0 should had described better what is a “menu” with regards to aria-haspopup.

ARIA 1.1 https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup aria-haspopup has several values: true, false, menu, listbox, grid, etc.

ARIA 1.0 https://www.w3.org/TR/wai-aria-1.0/states_and_properties#aria-haspopup aria-haspopup are true and false. Also, in regards to #1736 :

Indicates the object has a popup, either as a descendant or pointed to by aria-owns.

The ARIA Authoring Practices help to clarify, see the combobox widget under “WAI-ARIA Roles, States, and Properties”: https://www.w3.org/TR/wai-aria-practices-1.1/#wai-aria-roles-states-and-properties-5

ARIA 1.1 If the combobox popup has a role other than listbox, the element with role combobox has aria-haspopup set to a value that corresponds to the popup type. That is, aria-haspopup is set to grid, tree, or dialog. Note that elements with role combobox have an implicit aria-haspopup value of listbox.

ARIA 1.0 the element with role combobox has a value for aria-haspopup of listbox. Note that elements with role combobox have an implicit aria-haspopup value of listbox.

Please also notice the 1.1 pattern is different from the one implemented in the Mentions plugin because it requires a container with role=combobox, with a textbox and listbox as children. So the pattern to take into consideration for the current implementation is the 1.0 one.

Please see also the examples linked there: https://www.w3.org/TR/wai-aria-practices-1.1/#examples-1 they all use aria-haspopup.

Also, worth noting aria-haspopup is a property, not a state. That means its value shouldn’t change dynamically. It should stay unchanged. Please notice in the 3 examples of the 1.0 pattern, this attribute is aways aria-haspopup="true" regardless if the “dropdown” is closed or open.

The reason for this is that aria-haspopup is a property that informs about a feature of the combobox. For example, screen reader users need to be informed they’re in a widget that conditionally renders a “popup”, whatever the popup actually is. They need this information before activating the widget.

[afercia]

@jessebeach sure then I guess it should be one of ['false', 'true', 'menu', 'listbox', 'tree', 'grid', 'dialog'] 🙂 I’d be more than happy if someone else wants to make a PR, given my time is very, very limited.

[jessebeach]

I guess the safer option would be not limiting the value and allow all of them?

@afercia I always hesitate to open the flood gates and allow anything. When we’re restrictive from the start, we reduce the risk of needing to claw back support.