aria-hasPopUp less is more

Updated 4th September 2023

I first tested and reported support in the critically acclaimed 2021 article hasPopup hasPoop. I then retested 09/02/2023 –  JAWS and NVDA, no change to results reported in 2021.

Movement at the station

latest testing…

Elation

The latest version of JAWS 2023 June update (released 20/6/2023) now supports all aria-haspopup values on button and link.

The latest version of NVDA 2023.2  (released 4/9/2023) now supports all aria-haspopup values on button and link.

Despondency no more

I thought NVDA had also implemented the same support recently, but on testing it found that although support has been implemented it has not yet made it into the release version.😑

Relief

Minimalism

I also found that Narrator now announces “has pop up” when the attribute is present on links and buttons, but does not announce the token values.

The Theory

In theory aria-haspopup can be really useful as a hint to screen reader peeps as to what type of content will pop up when they activate a control.

values for aria-haspopup

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 deprecated as a global property in ARIA 1.2.

Roles it can used on:

• application
• button
• combobox
• gridcell
• link
• menuitem
• slider
• tab
• textbox
• treeitem

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-haspopup is now good in latest JAWS, is better in latest Narrator,
  • The support for aria-haspopup is now good in latest NVDA
  • aria-haspopup is now a practical method to robustly convey information to screen reader users on Windows about pop ups of type listbox, grid, tree or dialog.

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.

Legacy 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 - opens grid">pick a date</button>

or use aria-describedby:

<button aria-describedby="grid">pick a date</button>

<span hidden id="grid">opens grid</span>

or use CSS :after

<button id="grid">pick a date</button>
#grid::after 
{content: " opens 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.