“a popup is generally presented visually as a group of items that appear to be on top of the main page content”.
Elements can trigger other types of pop-ups, including dialogs, windows and tooltips. Arriving at an implementable cross-platform solution can be difficult. This is due, in part, to the different ways in which screen readers announce
aria-haspopup=true. This differs by screen reader and by element. For example:
- On a link or a radio button JAWS announces
aria-haspopup=trueas “has pop up.”
- On a button JAWS announces
aria-haspopup=trueas “button menu.”
- NVDA announces
aria-haspopup=trueas “sub-menu” on every element.
Because of NVDA’s close adherence to the WAI-ARIA specification, you can see why using
aria-haspopup=true to indicate the triggering of anything other than a sub-menu could be confusing for users of NVDA. This is why at this current time, SSB recommends that developers follow the WAI-ARIA specification and only use aria-haspopup to indicate the appearance of menus.
This raises the question of how to announce the appearance of anything other than a menu. Visually hidden text positioned absolute+left -9999px using CSS disables direct touch access and explore-by-touch with screen readers used on mobile devices. This leaves no reliable cross-platform solution for indicating the appearance of a dialog, window or tooltip. This is why a bug has been filed with the W3C to update the WAI-ARIA specification with the aria-poptype attribute. The aria-poptype attribute would contain a defined type ‘keywords’ and optionally a supplementary author string to provide additional information. You can read the bug and file comments on Bug 25851 – ER: allow authors to declare type of popup from the triggering element: menu, dialog, etc.
You can test out current implementation of the aria-haspopup attribute by user agents and assistive technologies on the aria-haspopup page on Level Access Labs.