37

I have it on good authority that aria-haspopup is appropriate for sub-menus (such as a popup context menu or sub-level menu). It's used on jQuery UI Selectmenu and also used in this great example.

What I've not been able to find out is whether aria-haspopup is applicable in the following 2 examples:

  • Informational popovers such as Bootstrap's - used for contextual information, but not containing any links
  • Pop-up browser windows - e.g. links with target="_blank"

Is aria-haspopup appropriate in those situations? If not, are there ARIA attributes that should be used instead?

Community
  • 1
  • 1
francois
  • 603
  • 1
  • 5
  • 11

2 Answers2

34

Officially it should be used only for menus or sub-menus, from the ARIA spec 1.0:

Indicates that the element has a popup context menu or sub-level menu.

The Whatsock style guide covers this under the 'modals' section:

It might sound like a good idea to notify screen reader users that a 'Popup' is attached by adding the attribute aria-haspopup="true" to the triggering element, but this is not a good idea. ... In short, don't use aria-haspopup unless you are triggering a menu.

There is some discussion about expanding the meaning in future revisions, but for the moment assume it is for menus.

I gave an answer about Bootstrap's tooltips which should help.

For pop-up browser windows, those are announced by screen readers anyway, no extra markup is needed. (NB: It helps to include a visual indicator of a new window for screen magnifier users.)

Vincent Cantin
  • 16,192
  • 2
  • 35
  • 57
AlastairC
  • 3,277
  • 21
  • 15
  • 1
    I think this is a great answer. One more thing to note, is that MS uses this property to enable touch accessibility for "hover" items in their browsers: https://msdn.microsoft.com/en-us/library/dn265029(v=vs.85).aspx So while *semantically* the question and answer are on the right track, in practice I have needed this attribute to enable necessary "hover" i.e. mouseover effects (when the design was not up to me to actually fix properly). So with mixed feelings, somewhat unfortunately (though cool to see MS using semantic info in the first place) there are practical uses other than popup menus. – natevw Nov 06 '15 at 20:21
  • target="_blank" is not supported by most screen readers. https://www.powermapper.com/tests/screen-readers/navigation/a-target-blank/ If a visual indicator is included it must be in an accessible way. – Steven Mouret Jul 19 '21 at 15:56
24

The WAI-ARIA 1.1 spec (which is the current one at the time of writing) expands the use of aria-haspopup compared to the 1.0 spec:

[aria-haspopup] indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.

A popup element usually appears as a block of content that is on top of other content. Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog, and that the value of aria-haspopup matches the role of the popup container.

So you should set the value of aria-haspopup to the same value as the role attribute on the triggered element. If set to true it will be interpreted as menu to align with the 1.0 spec where aria-haspopup was only meant for menus.

Note this however about tooltips (like Bootstrap popovers):

A tooltip is not considered to be a popup in this context.

Pop-up browser windows are not HTML elements on the page so anchor elements with target="_blank" should not have a aria-haspopup attribute.

Community
  • 1
  • 1
jeanfredrik
  • 563
  • 4
  • 14
  • 1
    This answer describes the intended use of aria-haspopup in ARIA 1.1, but note that support for the new values among browsers and assistive tech is currently poor. – andrewmacpherson Feb 25 '19 at 07:38