Clarify usage of aria-haspopup

[scottaohara]

Coming out of our discussion of #999

We should review aria-haspopup and determine if there should be stronger guidance about what the expectations are for when the attribute should be used, and what sort of variations in behavior should be expected when using the different allowed values.

For quick reference, the current values are:

• false (default)
• true and menu
• listbox
• tree
• grid
• dialog

Specifically regarding the dialog value, it was mentioned on the call that when this should be used is ambiguous right now.

As a quick sampling of how this particular value is presently communicated by screen readers when used on a button element:

Latest JAWS and NVDA both treat a button aria-haspopup=dialog as a menu button, and produce announcements as if the value were true or menu.

iOS VO announces "shows popup. double tap to activate a picker".

macOS VO announces it as a "popup button" similarly to a select element's announcement.

[scottaohara]

To help move discussion on this along I created a test page noting how VoiceOver, JAWS and NVDA expose (and by that I mean mostly don't) any of the specific pop-up values. In most cases, the aria-haspopup is indicated by changing the element to append the announcement "pop-up" or "menu" or "submenu".

Only with JAWS with Chrome and Firefox did the special designations get announced on links.

[jnurthen]

NVDA issue for aria-haspopup is https://github.com/nvaccess/nvda/issues/8235

[carmacleod]

JAWS issue for aria-haspopup is https://github.com/FreedomScientific/VFO-standards-support/issues/33

[scottaohara]

i'm going to move this to 1.3. I don't think there's time, nor urgency, to tackle this in 1.2.

[mfairchild365]

For whatever it is worth, the latest versions of VoiceOver for iOS and MacOS now fully support all values for aria-haspopup. Details and test results: https://a11ysupport.io/tests/tech__aria__aria_haspopup_attribute

[scottaohara]

that's great to hear. thanks @mfairchild365

[joanmarie]

Just out of curiosity, how important is it to explicitly announce the popup type? If a user is on something with a popup, and activates that popup and winds up in a grid, will the user be completely confused if the screen reader failed to notify them in advance that a grid would appear?

As a sighted user, I don't know in advance what is going to pop up when I activate something with a pop up. I just activate it and see what happens. If a grid appears as a result, my conclusion is that the grid appeared because it's the popup.

To me, tacking on the type seems like it might be unwanted chattiness.

If it's truly important, I can add announcement in Orca. But I was operating under the assumption that this information was mainly of use to the screen reader itself (e.g. an explanation regarding why a grid is claiming to be showing).

[joanmarie]

Related question: Combo boxes by default pop up a listbox. Is it considered a screen reader "failure" if it doesn't announce that a combo box opens a list box? Were I the user, my reaction to that announcement might be "of course it does. why are you telling me this?"

[mfairchild365]

That's a really good question. There are cases where I think it is important to explicitly announce the popup type. For example, many ARIA based <select> elements have a button with aria-haspopup='listbox'. The listbox itself is not displayed until after the button is activated. In these implementations, there is often a visual hint that the button opens a listbox such as a down arrow to the right of the button label. So, aria-haspopup='listbox' conveys that same visual information. The APG has an example of this in the Collapsible Dropdown Listbox Example.

It may be less important for other values, but I think there are situations where it is very important.

[carmacleod]

@joanmarie

Just out of curiosity, how important is it to explicitly announce the popup type?

As long as the screen reader doesn't say "menu button" when aria-haspopup="dialog". :)

[scottaohara]

It may be less important for other values...

and there in lies the source of this issue being created. :)

[joanmarie]

Ok, I just implemented support for it in Orca master: https://gitlab.gnome.org/GNOME/orca/commit/25c64254

Edit: because duh https://gitlab.gnome.org/GNOME/orca/commit/8368b43. Long day.

Many Orca users (at least those on the Orca mailing list) run Orca master in their production environments (bless their adventurous hearts). Let's see what they say (if anything).

[carmacleod]

@mfairchild365

there is often a visual hint

Good point. In the case of the APG Collapsible Dropdown Listbox Example, NVDA (for example) says "menu button", which is almost correct, and even has similar keyboard interaction, but doesn't tell the user that they will be "selecting the button's value from a list". (which is kind of an important thing to know, and makes me wonder whether that example should be a combobox instead :) ).

Edit: I suppose if NVDA had instead said "Neptunium popup list button" or "Neptunium button, opens listbox", then that would be an indication that the chosen list item would end up as the button's text.

[carmacleod]

Ok, I just implemented support for it in Orca master

Nice! Would love to know what the Orca users say. Please do let us know.

[joanmarie]

That's a really good question. There are cases where I think it is important to explicitly announce the popup type. For example, many ARIA based <select> elements have a button with aria-haspopup='listbox'. The listbox itself is not displayed until after the button is activated. In these implementations, there is often a visual hint that the button opens a listbox such as a down arrow to the right of the button label. So, aria-haspopup='listbox' conveys that same visual information. The APG has an example of this in the Collapsible Dropdown Listbox Example.

When an Orca user (using the stable version) encounters that button, Orca says the following:

Choose an element: Neptunium push button.

When you hear that you know what you need to do conceptually, namely choose an element. In addition, you know what the current choice is, namely Neptunium. If Neptunium ain't your element, what do you do? It's clear that you push the button.

When the same Orca user presses the button, the listbox appears and Orca says the following:

Expanded Choose an element: List with 26 items ✓ Neptunium.

Depending on user settings, Orca may also tack on:

1 of 26.

That should be enough for the user to know what to do in the list.

I will grant you that failure to present an equivalent of the downward pointing triangle means there is a moment when sighted users have more info than blind users. But I don't personally believe that one moment is significant: You have to choose an element, you're on the thing which lets you choose elements, you activate it and the element-choosing-widget is described so you can choose the element.

But now, Orca master tacks on:

opens listbox

That makes presentation longer. Speech output is already slower than visual output. And as I describe above, I'm not convinced that longer presentation buys the user anything. :woman_shrugging:

[mfairchild365]

Thank you, @joanmarie - that is insightful and you bring up many good points. I agree that in the specific APG example, there is enough information for a user to infer that this button probably opens a list box or some other thing that lets me change the value. I'm less willing to say that holds true for other situations where the name and/or value might not be as clear. Additionally, explicitly conveying the fact that this button opens a listbox might lessen the cognitive load required for someone to understand what they need to do to adjust the value. That's just a hunch, and I don't know that to be true.

I love that you made the change in an effort to collect feedback from end-users. I'm looking forward to hearing the results of that. IMO, that sort of research is one of the best ways to drive decisions like this.

But I was operating under the assumption that this information was mainly of use to the screen reader itself (e.g. an explanation regarding why a grid is claiming to be showing).

I'd like to better understand this statement. How would this information affect the internals of how a screen reader works? If an author did not provide this attribute, how might that impact the experience of the end-user if it is just used for the screen reader itself?

[scottaohara]

How would this information affect the internals of how a screen reader works? If an author did not provide this attribute, how might that impact the experience of the end-user if it is just used for the screen reader itself?

you mean the attribute, or specific token values of the attribute?

[mfairchild365]

Good question. Both.

[brennanyoung]

I suggest that the problem is not that NVDA fails to announce the other popup types, but that it specifically mentions one of them (arbitrarily chosen by tech history), but not the others.

If the rationale for not announcing the popup role is to reduce chattiness, why does NVDA announce "menu" or "submenu" (which isn't even an aria role) in the first place? Isn't that 'chattiness' too?

Either announce all the enumerated popup roles mentioned in the spec, or announce none at all, and make a briefer, more generic announcement about 'a' popup.

No matter what, a dialog is very much not a menu. Can't even get around this mislabelling with aria-roledescription in this case.

[joanmarie]

Nice! Would love to know what the Orca users say. Please do let us know.

Not a peep. So they're not bothered by it at least. Though I don't know how much they're encountering it in the wild.

[sinabahram]

I think it is critical to talk about behavior in addition to announcement. Please note that aria-haspopup="dialog" results in forms mode being enabled upon invocation in Jaws, and I believe insert mode in NVDA as well. This is highly problematic because the resulting modal dialog, let's say, is then not navigable as a document, independent of its role. This is something that comes up quite a bit on websites we work with developers on where they feel they are doing the right thing, and we tell them, don't at all implement aria-haspopup="dialog" because you will drastically degrade the experience for most screen reader users.

Regarding announcement, it is a good idea to give a priori information to the user when possible, I feel, because it helps set expectations. The metric I always use here is that for an eyes-free user, the cost of undo is almost always higher, often times much higher, than for a mouse or otherwise sighted user (just choosing these two groups for argument, obviously there are many more). Therefore, a minor annoyance can be dismissed with a flick of a wrist, but may take tens of seconds or minutes for a screen reader user to achieve the same result.

As a result, this heads up, I feel, is both useful and honestly necessary. Note that native platforms sometimes have paradigms for this, such as the '...' indicating a new window in MS Windows buttons.

Also, I just wish to say major props to Joanie for implementing this in Orca. Thank you for doing so.

[JAWS-test]

Please note that aria-haspopup="dialog" results in forms mode being enabled upon invocation in Jaws, and I believe insert mode in NVDA as well.

I have tested this in Chrome and Firefox, with JAWS 2019, JAWS 2020, and NVDA 2019.2.1 Neither for links nor for buttons did using aria-haspopup=dialog lead to switching to forms mode. Nor did the use of role=dialog switch to forms mode. I could read at any time with the virtual cursor (i.e. with the arrow keys).

@sinabahram: Do you have a link to the page where the problem occurred? I suspect that the cause for switching to forms mode was different from having aria-haspopup=dialog

[sinabahram]

RE forms/insert mode with aria-haspopup, can you please provide a test page, so I can compare results over here? We’re also going to code up some samples over here to make sure we can reproduce the behavior reliably, and I’ll share those as well.

[JAWS-test]

@sinabahram : this is my test page

[sinabahram]

Thanks for the test page. I just replicated the behavior with Jaws and Chrome, latest versions.

I hit that button once, and it turned on forms mode, then turned it off, and then focussed the heading. I then closed the dialog by hitting yes or no, and I then just reproduced the exact same actions; however, this time, the forms mode didn’t toggle off.

[JAWS-test]

This is strange, I have no change to forms mode (JAWS 2020, Chrome 79).

[sinabahram]

Helps, and maybe it doesn’t, I have the same config over here, same results. Also, this has always been the behavior for as long as I can remember.

[stes-acc]

I think it is high time that the WAI-ARIA group agrees at least on a speech output proposal for screen readers as part of the definition, for instance when they replace booleans by string-based enums. Otherwise it will end up in a support chaos.

I know that ARIA intentionally does NOT define speech output but we can expect that discussions about those WILL appear otherwise as this thread reveals gracefully.

We can and should this clarify beforehand with no ambiguities.

[jscholes]

@JAWS-test and @sinabahram, could you confirm your Auto Forms Mode setting value, and test the below assertions? They apply in both Firefox and Chrome for me.

Activating the button within the provided sample causes forms mode to be activated when focus enters the dialog, if Auto Forms Mode is set to "Manual". If it is set to "Auto" or "Semi-Auto", this does not happen.

In Firefox, just placing focus on the button causes forms mode to be activated if Auto Forms Mode is set to "Auto" or "Semi-Auto", but not if set to "Manual".

The first assertion seems illogical to me. If I have Auto Forms Mode completely switched off, I don't expect opening a modal using a button with aria-haspopup="dialog" to completely go against that setting.

For the second assertion, the automatic mode change does only apply when Auto Forms Mode is enabled. But it only applies in a single browser, and is completely unnecessary. Nobody needs forms mode switched on to press a button.

[jscholes]

I should also note that NVDA never turns off browse mode when entering a modal, unless the control to receive focus requires such a change. A text field, for instance.

[sinabahram]

@jscholes, this makes sense. The first thing I do is turn forms mode to manual.

[JAWS-test]

I have tested the example at https://codepen.io/jaws-test/pen/jOEdBBz with Chrome. Only in one case JAWS 2019 switches to forms mode: When I open the dialog box by activating the button and have turned off automatic forms mode in the JAWS settings manager (forms mode = manual)

[jscholes]

@JAWS-test Thanks for testing. By "Only in one case", do you mean that this only happened once? Or that it consistently happens with Auto Forms Mode set to "Manual".

[JAWS-test]

Sorry for the vague language. No, it always happens with the button with aria-haspopup in the dialog when Auto Forms Mode is off. "Only once" means that it does not happen in the following cases:

• when navigating to link and button
• when the link is activated
• with Forms Mode "Auto" or "Semi Auto"

[stes-acc]

We should also clarify what value aria-haspopup should have if container has role dialog but the only instance inside is a tree, a menu etc.

These things HAPPEN because developers think of popops being MODAL/NON-MODAL and all available (APG) examples available don't even mention modality of roles tree, menu and so on just saying menu ec. is root container.

The caveat with this is that dialog derives from window whereas menu etc. derives from widget. Window has clearly defined modal/non-modal properties whereas for widget this is just not defined, which causes confusion among devs.

So two questions for clarification:

The ARIA spec is lacking a sentence like "menu role used as container is always modal/non-modal" (pick your preference)

Alternatively, is is OK to "wrap" such popups in dialogs with aria-modal="true/false" and give aria-haspopup the value of the inner content IF THIS IS THE ONLY CONTENT IN THE DIALOG?

[mcking65]

I agree with @joanmarie that we should be questioning how much value the aria-haspopup tokens do or even could provide to users. I also agree with @sinabahram that recovering from unintended actions is often more difficult for screen reader users. However, I don't think any of the aria-haspopup tokens can reduce the likelihood of unintended actions that are difficult to undo.

Unfortunately, I played a big part in getting the aria-haspopup tokens into the spec; I drafted the pull requests as part of efforts to resolve combobox issues. As we all know, ARIA 1.1 combobox changes were pretty much a disaster, and it was a lot of work to clean up the mess in ARIA 1.2. The aria-haspopup tokens are fall out from that mess, and I see the inconsistent understanding and support as forms of collateral damage, and I regret supporting their addition to the spec. I now see the tokens as solutions looking for a problem.

We added the new haspopup tokens for the combobox role in ARIA 1.1 because there was some concern that screen readers need to know that the combobox would open something other than a listbox. I don't recall the origin of the concern. I have no recollection of how much anyone, including me, questioned it. We may be able to find more information in meeting minutes from 2016 or so. Regardless, I don't think whatever concerns were expressed at that time have been manifest in practice. So, I don't think screen readers need an attribute that tells them what kind of popup a combobox will open.

In addition, because we were not using the process we have today that requires us to develop authoring practices before adding features to the stable branch, we didn't do a good job of working through all the ramifications of the new values on accessibility APIs and assistive technologies. For instance, we didn't adequately consider the consequences related to the fact that aria-haspopup on a button changes the role of the button to menu button in some accessibility APIS. So, when people started adding haspopup equal dialog on buttons, they got menu buttons that open dialogs -- talk about confusing users!!

If we would have been using today's ARIA development process for ARIA 1.1, then, maybe we would not have changed aria-haspopup.

In the near term, it is not clear to me that there is any real world value to be gained from modifying accessibility APIs and browsers so that assistive technologies can know in advance what kind of popup an element will open. Even if there is some theoretical value, I think we would be better off focusing resources on repairing other ARIA support gaps that do not require accessibility API changes and cannot be avoided by authors. In this case, the solution for authors is simple -- don't use the unsupported token values. Doing so does not create any negative side effects for users.

So, a stopgap corrective course of action could be to invalidate use of any aria-haspopup token except for false, true, and menu unless applying it to a combobox. The combobox exclusion is simply because it is already baked into the pattern, and we don't need any more churn there.

Later, if we come to consensus around additional usage, it would be straightforward to expand support. Fortunately, since we already have some implementation, it would be feasible to research and experiment before charting additional changes, whether they be expanding or removing support. If research shows no benefit, we should consider deprecation. While potentially more frustrating in the near term, it might be the better solution for the overall health of ARIA.

[JAWS-test]

I have never understood why aria-haspopup can have different values. While sometimes there is a visual indication that something is opened by an element, I don't know any example where it is visually recognizable in advance if a listbox, tree, grid, menu or dialog is opened. So why does this information need to be perceptible in advance with AT and not visually? Actually, it would be sufficient with AT if this information could be perceived as soon as the additional content is displayed. And this is the case because the content then has the ARIA role listbox, tree, grid, menu or dialog. One could even go one step further and abolish aria-haspopup completely and replace it with aria-expanded. aria-expanded also transmits the information that an element can be opened or closed. Visually, there is often no difference between elements marked with aria-expanded and those marked with aria-haspopup. Both elements have a triangle icon to the right of the label.

For instance, we didn't adequately consider the consequences related to the fact that aria-haspopup on a button changes the role of the button to menu button in some accessibility APIS

Can this not be changed? (see https://github.com/w3c/core-aam/issues/51)

[stes-acc]

Visually, there is often no difference between elements marked with aria-expanded and those marked with aria-haspopup.

True, but the technical nature of the popup container may matter. Popups are separate nodes not necessarily adjacent in DOM node sequence and have often different z-order.

In addition, aria-expanded is a state attribute, whereas aria-has-popup isn't. They may require a different API mapping path category which is relevant on some platforms.

[carmacleod]

@mcking65 said:

In this case, the solution for authors is simple -- don't use the unsupported token values. Doing so does not create any negative side effects for users.

I just want to mention one tiny use case. We have a select-only combobox that opens a dialog. The spec for combobox says:

Elements with the role combobox have an implicit aria-haspopup value of listbox. If the combobox popup element has a role other than listbox, authors MUST specify a value for aria-haspopup that corresponds to the role of its popup.

Of course, unless we rewrite the spec, validators would complain if the token didn't match (a negative side effect for authors 😄 ).

However, ignoring that little problem for the moment... in this particular use case, I think the token could be useful. A sighted user activating this combobox will not be terribly surprised when they get a dialog. It is visually apparent that the dialog is the popup, because the top of the dialog is aligned with the bottom of the combobox (etc), as well as other visual cues like the dialog is transitioned in when the combobox is opened. So I don't think it's a "cognitive leap" for the sighted user to understand that they dropped down a combobox and got a dialog.

Just guessing, though, that it might be a bit different for a screen reader user. Most of the time, dropping down a combobox gives a listbox. If it's a grid or a tree, well, they're kind of list-like, so no big surprise. But if you're suddenly in a dialog, the reaction might be "Huh? What just happened?". So I'm thinking it might be useful to know ahead of time that the combo has a dialog. Perhaps something as simple as, "Repository combobox, collapsed dialog". Or (more verbose but potentially clearer), "Repository combobox, collapsed, opens dialog".

[JAWS-test]

@carmacleod: Currently neither NVDA nor JAWS outputs aria-haspopup in any way (tested with Chrome and Firefox at https://codepen.io/jaws-test/pen/abZdbWr). Thus aria-haspopup is completely superfluous. Regardless of the fact that the value is in aria-haspopup is not output, I think that a combo box doesn't need aria-haspopup anyway, because everybody knows that something can be opened there (and whether it's a listbox or a grid is a surprise for everybody). aria-haspopup is in my opinion only useful on elements like a button, where it is not clear from the beginning whether you are submitting a form or opening a popup

[masi]

IMHO users would benefit from being told that a button opens a dialog. It's a shame that neither JAWS nor NVDA adopted the ARIA 1.1 values.

[guyhickling]

how important is it to explicitly announce the popup type?

I have always considered that aria-haspopup="dialog" would be incredibly useful to screen reader users, if it worked, for two reasons:

a) It lets them know that in order to get back to where they were they have to do something (either look round for a Close button, or press Esc). This is quite different from drop-down content (e.g. accordion style drop downs), where you don't leave the page and you'll eventually get back to the rest of the page content if you just go on navigating long enough.

b) Telling users in advance lets them know what should have happened, in the event that it does not. The greatest problem with dialogs is that most developers do not know how to make them accessible.

And therein lies the difference between screen reader users and other people. A keyboard-only user can see immediately that a dialog has opened, even if they then find they and the focus have been left out in the cold.

But a screen reader user has no such information. If focus isn't placed in the dialog, it won't be announced. They are left to hunt around to try to find out what happened when they pressed the button, but won't be able to discover any change on the page. It's just complete silence for them. But around a half of all developers either do not understand that elementary matter of focus, or they're using frameworks that don't manage focus, and testers don't test for it. That is why I consider the dialog announcement MUST be made in advance on the button. (I advise developers to append "Opens dialog" as hidden text to the button or link text since haspopup doesn't work.)

Even when a screen reader user is placed in a dialog, they are often given no announcement about it (if the dialog role isn't added), and often the Close button is unlabelled and/or not in the tabbing order so that clue isn't available either.

To be fair, there are so many things to get right when creating a dialog - placing focus on it, using the dialog role, adding aria-labelledby to title it, trapping keyboard focus, labeling the Close button, and so on. It's an art in itself and it's easy to see why developers make such a hash of it, or don't even know about it. Whereas adding a single aria-haspopup attribute to the initial button is a very simple thing for developers to learn. It tells screen reader users, in one go, what is supposed to happen, even if they get left out later!

Just one point, I don't think AT makers should amend the API when they find aria-haspopup, for reasons such as the ones @sinabahram mentions above. They should just announce the impending dialog to the user, and wait to find out what content is inside the dialog before reacting.

And I do think W3C should offer recommended wordings for screen reader announcements for all ARIA attributes. Not statutory wordings - AT manufacturers could still word something differently if they felt it best in a particular case. But a recommended list would stop the current free-for-all that just confuses users. After all, that's what ARIA is for in part, to tell AT what to do, so why not tell them what to say as well? Most screen reader users use more than one reader even if only between their PC and mobile phone. It must be very confusing when switching from one to another to hear such widely differing announcements for the same thing!

About the differences between trees, text dialogs, grids and the rest, I'm less concerned. Once a user lands in a dialog they'll find out what's there. It's when they don't land in it that's the real problem.

Meanwhile it would also be nice to persuade the screen reader manufacturers to put some effort into recognising the haspopup attribute (full marks to Apple there!) instead of just ignoring it. It isn't that difficult, and it would help the users so much. Perhaps the best solution would be to junk haspopup, create a new ARIA attribute for buttons that open a dialog, specify what words should be announced for it, and this time plug it strenuously with the screen reader makers until they capitulate!

[masi]

@guyhickling I agree with you. Popup vs dialog is the main distinction. And if screen reader developers have ignored the values for years for no apparent reason let's try it with aria-hasdialog.

[sinabahram]

Let's get folks to implement what is there now, not suggest a new attribute that does a subset of what already exists. If they have objections to implementing haspopup, maybe we an spend a fraction of the time it would take to author, debate, build consensus around, and eventually publish a new attribute to just get the AT vendors to implement haspopup or at least document their objections.

[carmacleod]

@sinabahram @jnurthen I've created https://github.com/w3c/core-aam/pull/86 to address this by making the core-aam mappings match the ARIA spec. Would love reviews... 2 line fix.

[mcking65]

@guyhickling wrote:

I have always considered that aria-haspopup="dialog" would be incredibly useful to screen reader users, if it worked, for two reasons:

a) It lets them know that in order to get back to where they were they have to do something (either look round for a Close button, or press Esc). This is quite different from drop-down content (e.g. accordion style drop downs), where you don't leave the page and you'll eventually get back to the rest of the page content if you just go on navigating long enough.

Accordion style drop downs (disclosures) use aria-expanded, not aria-haspopup. They do not move focus or change mode when using JAWS or NVDA.

Other dropdowns, such as menus or listboxes, require JAWS and NVDA users to do something to get out, e.g., escape, enter, tab, you can't read your way out with arrow keys.

b) Telling users in advance lets them know what should have happened, in the event that it does not.

I appreciate the user-centric intention you are expressing, and empathize with people who struggle to help developers create accessible dialogs.

However, as a user, if the button were to tell me it opens a dialog and then when I activate the button focus doesn't go into a dialog, the attribute on the button that told me about the dialog doesn't necessarily help me. I have no way of knowing if the button was supposed to open a dialog. I'm not going to assume that it should just because it said so. If it didn't open a dialog, I could overlook what the button really did and end up even more frustrated.

I don't advocate support for aria-haspopup="dialog" based on its potential to give developers a way to tell users what their buttons should do as opposed to expecting the developer to make the button do what it should do.

[masi]

@guyhickling Obviously the announcement for aria-haspopup an what exactly happens after a button activation must match. In ARIA 1.0 there was only the value "true". Jaws and NVDA decided to read out "menu" instead of "pop-up". I assume that this was the reason for the values introduced with ARIA 1.1.

For me the point is not to add new attributes for the sake of it. I'd be content with screen readers stopping to announce "menu" when the button opens a dialog and moves the focus. Currently aria-haspop makes only sense in the real world when used with a matching role="menu". But that's not the fault of the spec.

For me the new attribute carries the hope that screen reader developers begin to see the point in telling the users about opening a dialog. Modern web designs has more and more dialogs. OTOH application menus in the style of ARIA role "menu" are rare.

[zelliott]

I'm curious what the a11y experts on this thread recommend developers do for now for controls that open dialogs. Should we add aria-haspopup="dialog" and live with the poor screen reader support? Should we add aria-haspopup"true"? Should we append some informative string "opens pop up dialog" to the control's label or description?

This article recommends the latter. Other comments on this thread seem to imply using aria-haspopup with some value.

[JAWS-test]

I would always use aria-haspopup with the correct value. Sometime I guess the output will be correct, hopefully....

As written above, I don't think the wrong output of aria-haspopup is problematic, because a sighted user can't see what will happen at the link or button beforehand either. Only after activating the link or button, the sighted user can see what happened - and so the AT user should also be able to correctly perceive what happened after activation, e.g. by mark the dialog with role=dialog, labeling it, giving it focus, etc.

[jscholes]

@JAWS-test

I don't think the wrong output of aria-haspopup is problematic, because a sighted user can't see what will happen at the link or button beforehand either.

This is a bit kcontradictory IMHO. If a sighted user doesn't know what a button will do when they activate it, why should the screen reader user know what they don't? More importantly, why should the screen reader user be given information that is likely to be incorrect when a sighted user is given no information at all?

For me the decision comes down to equity. If a client wants to surface that a button will open a modal for all users, we'll talk about it and find a solution that works for everyone. Otherwise, knowing that most screen readers will give buttons with aria-haspopup="dialog" a role of menubutton, it isn't currently worth it. I'm not a fan of using ARIA to the letter of the spec when I know that screen readers aren't along for the ride.