At the moment, ATs have no way of knowing that a given widget has an associated pop-up menu. There is a relation [1]:

ATK_RELATION_POPUP_FOR
Indicates that an object is a popup for another object.

However, that is designed for ATs to know what widget caused a showing popup to appear. While a reciprocal relation could be created to point from the widget to the popup, it will not solve the problem in cases where the popup is not created unless and until the widget is activated. We see this quite a bit with web apps.

In order for ATs to identify that a given widget has the potential to show a popup menu, adding a new state seems like the best solution. This new state would be similar conceptually to the "-able" states (expandable, selectable, focusable). But popupable seems like a bad idea. ;)

Proposed state and documentation, borrowed from the ARIA documentation [2]:

ATK_STATE_HAS_POPUP

Indicates that the object has a popup context menu or sub-level menu which may or may not be showing. This means that activation renders conditional content. Note that ordinary tooltips are not considered popups in this context.

[1] https://developer.gnome.org/atk/stable/AtkRelation.html#AtkRelationType
[2] http://www.w3.org/TR/2011/CR-wai-aria-20110118/states_and_properties#aria-haspopup