Update: 09/02/2023 – retested in latest JAWS and NVDA, no change to results reported in 2021
In theory aria-haspopup could be really useful as a hint to screen reader peeps as to what type of content will pop up when they activate a control.
The Theory
| Value | Description |
|---|---|
| false (default) | Indicates the element does not have a popup. |
| true | Indicates the popup is a menu. |
| menu | Indicates the popup is a menu. |
| listbox | Indicates the popup is a listbox. |
| tree | Indicates the popup is a tree. |
| grid | Indicates the popup is a grid. |
| dialog | Indicates the popup is a dialog. |
Note:
This property is being deprecated as a global property in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.
The Current Reality
- Results from the test file, using latest browser, OS and screen reader versions:
- Modern browsers expose aria-haspopup in accessibility APIs.
- The support for
aria-haspopupis patchy across popular Screen readers. - The patchy support in Screen readers means
aria-haspopupis not currently a practical method to robustly convey information to screen reader users on Windows about pop ups of typelistbox,grid,treeordialog.
| Value | JAWS
|
JAWS
|
NVDA
|
NVDA
|
VoiceOver
|
VoiceOver
|
Narrator
|
Narrator
|
|---|---|---|---|---|---|---|---|---|
| false (default) | button ✔️ | link ✔️ | button ✔️ | link ✔️ | button ✔️ | link ✔️ | button ✔️ | link ✔️ |
| true | button menu ✔️ | link hasPopUp menu ✔️ | menu button subMenu ✔️ | subMenu link ✔️ | menu pop-up button ✔️ | Menu pop-up link ✔️ | button collapsed ✔️ | link ❌ |
| menu | button menu ✔️ | link hasPopUp menu ✔️ | menu button subMenu ✔️ | subMenu link ✔️ | menu pop-up button ✔️ | Menu pop-up link ✔️ | button collapsed ✔️ | link ❌ |
| listbox | button menu ❌ | link hasPopUp listbox ✔️ | menu button subMenu ❌ | subMenu link ❌ | listbox pop-up button ✔️ | listbox pop-up link ✔️ | button ❌ | link ❌ |
| tree | button menu ❌ | link hasPopUp tree ✔️ | menu button subMenu ❌ | subMenu link ❌ | tree pop-up button ✔️ | tree pop-up link ✔️ | button ❌ | link ❌ |
| grid | button menu ❌ | link hasPopUp grid ✔️ | menu button subMenu ❌ | subMenu link ❌ | grid pop-up button ✔️ | grid pop-up link ✔️ | button ❌ | link ❌ |
| dialog | button menu ❌ | link hasPopUp dialog ✔️ | menu button subMenu ❌ | subMenu link ❌ | dialog pop-up button ✔️ | dialog pop-up link ✔️ | button ❌ | link ❌ |
Note that how the UI is conveyed aurally differs across screen reader. This is definitely not something that we need concern ourselves with. There is no normative or informative document as to how HTML UI is to be announced to people by screen readers.
Oh poop! What can we do?
Some suggestions
Leave the aria-haspop attribute off an element in cases where the Aural UI is misleading/incorrect and instead:
Add the hint to the accessible name, for example:
<button aria-label="pick a date - has pop up grid">pick a date</button>
or use aria-describedby:
<button aria-describedby="grid">pick a date</button>
<span hidden id="grid">has pop up grid</span>
or use CSS :after
<button id="grid">pick a date</button>
#grid::after
{content: " has pop up grid";
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px; }
See the Pen
suggested aria-haspopup work arounds by steve faulkner (@stevef)
on CodePen.
5 replies on “hasPopup hasPoop”
Thanks for the article.
For future reference, it would be useful to know which OS/Browser/screen reader combinations you tested with?
Also, “Add the hint to the accessible name” – note that localisation is really important when adding hints ‘manually’; it would be good to call this out.
Thanks for the article! I noticed the Narrator results in the table are different from what I get — I hear “button, has popup” or “link (name), has popup” for all values of `aria-haspopup`.
Were you testing Narrator with a browser other than Edge? That can cause some weird results.
It’s such a shame that a seemingly easy to implement ARIA feature that has been around for years is still not fully supported.
I’m really torn in between making a good experience or adhering to the standard and urge everyone to make complaints at the vendor.
Interesting that aria-haspopup has more support on links (because technically a link is not the right type of control to trigger most of popups, this is the function of a button, so semantically I encourage people to use buttons but this could change it).
We need clearer communication between the standards community (ARIA in particular) and AT vendors. If there is no intent to support ARIA attributes, they shouldn’t be added to the standard. We already have too many ARIA attributes that are useful in theory but utter poop because they just don’t work. Having to keep track of which attributes AT vendors care to support and when authors have to work around those intensions rather does away with the usefulness and reliability of the standard as a whole.
I filed issues with both Jaws and NVDA over 2 years ago for not supporting token values of aria-haspopup, and still. These have not been resolved, I occasionally get updates on the threads, mostly people surprised this hasn’t been addressed yet.
A bit ranty, I know, but as someone guiding developers I am finding this to be frustrating.
I always recommend developers to append “, opens dialog” to the label text of buttons that open popup dialogs. That makes it similar to the “opens new window” text that is pretty well standard for links that open in a new window. I think similarity makes things easier for developers and users alike!
But I have to cringe at the JAWS response you highlight above. They do not support the dialog value on buttons, but they do support it on links, which is the wrong element for opening popup dialogs. Links are for going to another URL or anchor (Freedom Scientific – the clue is in the “href” attribute!!)