Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NVDA does not recognize the ARIA 1.1 values of aria-haspopup #8235

Closed
Wildebrew opened this issue May 4, 2018 · 29 comments · Fixed by #14709
Closed

NVDA does not recognize the ARIA 1.1 values of aria-haspopup #8235

Wildebrew opened this issue May 4, 2018 · 29 comments · Fixed by #14709
Labels
ARIA p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Milestone
2023.2

Comments

@Wildebrew
Copy link

Steps to reproduce:

With NVDA running, visit this Code P1. en demo.
2. Tab to the different buttons (the text explains what they should announce based on their aria-haspopup values).

Expected behavior:

NVDA should announce the value of aria-haspopup (or a more user friendly representation of the values).

  • "opens a dialog" for aria-haspopup="dialog"
  • "opens a listbox" for aria-haspopup="listbox"
  • "Opens a grid" for aria-haspopup="grid"
    and so on.

Actual behavior:

NVDA announces "has menu" for all values of aria-haspopup.

System configuration:

NVDA version: All versions

NVDA Installed or portable: N/A

Other information:The aria-haspopup entry in the ARIA 1.1 spec

Windows version: N/A

Name and version of other software in use when reproducing the issue:
Same problem with all browsers tested.

Other questions:

Does the issue still occur after restarting your PC?
None at this time.
@Neurrone
Copy link

Neurrone commented May 5, 2018

Cannot reproduce with firefox 60 and latest NVDA master (Version: master-15089,482e916c) - reads as it should.

@LeonarddeR
Copy link
Collaborator

@Neurrone: Are you sure? It looks like most if not all buttons announce sub menu.

@Neurrone
Copy link

Neurrone commented May 5, 2018

@LeonarddeR my bad, didn't read the issue description carefully enough.

Can also reproduce.

@LeonarddeR
Copy link
Collaborator

@jcsteh: May be you could elaborate on what Mozilla is intending to do with the new aria 1.1 values of haspopup?

@ehollig ehollig added the ARIA label May 6, 2018
@jcsteh
Copy link
Contributor

jcsteh commented May 8, 2018

Firefox already exposes this as the "haspopup" IAccessible2 object attribute. I don't think there's any reason to add any exposure beyond this.

Having said that, IMO, the justification for exposing this to screen reader users is unclear. Note that the spec does not require AT to present this information to users; it only requires that it be exposed so an AT can choose to present it if appropriate. I agree that saying "sub menu" is inappropriate, but I'm not convinced there's any need to reporting anything other than "has popup" for other cases. Does a sighted user know that something will specifically pop up a list, tree or dialog when they click it? In any case, this is just my $0.02; I'm not particularly motivated to argue about it at length. :)

@sasgrw
Copy link

sasgrw commented May 8, 2018

@jcsteh that's a valuable $0.02, but hypothetically, the sighted user could know what type of object will pop up, depending on the visuals. if there is a visual, then having an appropriately set (and surfaced) aria-haspopup makes sense.

@Wildebrew
Copy link
Author

Wildebrew commented May 9, 2018 via email

@LeonarddeR LeonarddeR mentioned this issue May 10, 2018
Closed
@LeonarddeR
Copy link
Collaborator

@jcsteh commented on 8 May 2018, 14:29 CEST:

I agree that saying "sub menu" is inappropriate.

Sub menu generally makes sense for STATE_SYSTEM_HASPOPUP, though, which makes NVDA's STATE_HASPOPUP a bit ambiguous.

@bramd: do you have anything to say about how you'd expect a screen reader to report these new haspopup values?

@Wildebrew
Copy link
Author

Wildebrew commented May 10, 2018 via email

@jcsteh
Copy link
Contributor

jcsteh commented May 14, 2018 via email

@Wildebrew
Copy link
Author

Wildebrew commented May 15, 2018 via email

@cannona
Copy link
Contributor

cannona commented Nov 27, 2018

Bump. Any updates on this? I think "opens dialog", "opens ..." would be best in this situation. I'm starting to see this used on a couple major sites, and NVDA still saying submenu is pretty strange for the user experience.

@LeonarddeR
Copy link
Collaborator

I think opens dialog makes sense, but opens grid, opens listbox are a bit weird. It is difficult to come up with something generic here.

@cannona
Copy link
Contributor

cannona commented Nov 27, 2018

@LeonarddeR Well, considering what the ARIA standard says about this property: "Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element."

So, in short, if you put an aria-haspopup on an element, that implies that it triggers or opens a popup, so I do think that it is an appropriate wording. I think the reason those sound weird is because it's quite common to encounter controls that open dialogs or menus, but not all that common to find controls that pop up a grid, or listbox. However, if you were to use aria-haspopup="grid" correctly on, for instance, a button, it would probably make sense to hear "opens grid".

In short, I think what would be unusual would be the use of aria-haspopup in those contexts, and not necessarily NVDA announcing it like that, but I'd love to hear your and other's thoughts on this.

@LeonarddeR LeonarddeR mentioned this issue Jan 23, 2019
Merged
muan added a commit to github/details-dialog-element that referenced this issue May 7, 2019
@muan
Remove aria-haspopup=dialog and add role=button
d46cc13 
- aria-haspopup=dialog
Using NVDA as an example: nvaccess/nvda#8235

- role=button
While the default summary role (disclosure triangle) could be
appropriate elsewhere, dialog's trigger element should be announced as
a button.
@muan muan mentioned this issue May 7, 2019
Merged
@Adriani90
Copy link
Collaborator

It would be really nice to have an information of what aria has popup will open when pressing enter on it. Often in complex enironments you know how data is presented but you don't want to exand every aria has popup button to see if it's the right data. So having this information would really boost efficiency in some situations.

@carmacleod
Copy link

@LeonarddeR

opens grid, opens listbox are a bit weird

grid and listbox will probably be more common on combobox than on button, so maybe not too weird there.

@Wildebrew
Copy link
Author

Wildebrew commented May 8, 2019 via email

@long2know
Copy link

I've recently been working with NVDA and stumbled upon this thread. Our accessibility testers have also pointed out, like in the previous comments, that NVDA incorrectly adds the extra role of "subMenu" for any element that has "aria-haspopup," whereas Edge w/ Narrator does not.

In every widget I'm using (like AngularJS uib-dropdown, uib-datepicker, custom datepickers / comboboxes, etc), the "subMenu" role is state which is pretty strange for the user.

Is there a workaround or planned time-line to address this issue?

@LeonarddeR
Copy link
Collaborator

I think we should just go with opens x. We could debate on whether ATs should expose this, but it's now part of an official spec, people expect NVDA to do something with it.

@jnurthen jnurthen mentioned this issue Oct 2, 2019
Closed
@carmacleod
Copy link

Just FYI, Orca now says "opens x". :)

@masi
Copy link

masi commented Nov 15, 2020

The discussion is surprisingly long. Just tested yesterday and NVDA announced simply "menu" for aria-popup="dialog". This is so confusing and makes the aria-popup ARIA 1.1 attribute values completely unusable.
The term pop-up itself is ambigous and I would actually never use it for a menu when talking about a UI with sighted devs.

@brandyscarney brandyscarney mentioned this issue Nov 16, 2020
Merged
7 tasks
@kolaps33
Copy link

I retested it now with Firefox 82.0.2 (64-bit) and Chrome Version 87.0.4280.66.
NVDA 2020.3

Just would like to point out that is still not working.

NVDA + Chrome narrates "menu button subMenu" for button with attribure "aria-haspoup", where doesn't matter what value attribute has.
NVDA+ Firefox narrates "button subMenu" for button with attribure "aria-haspoup", where doesn't matter what value attribute has.

@Wildebrew
Copy link
Author

Wildebrew commented Nov 27, 2020 via email

@masi
Copy link

masi commented Nov 27, 2020

Carolyn MacLeaod says that Orca does it right.

Sidenote: I din't undertstand why this is so hard to implement for NVDA and Jaws. May web pages have dialogs and an attribute that tells the user that a buttons open would be great. Maybe we can get another ARIA attribute in 1.2 if nobody wants to adapt the values of aria-haspopup introduced in 1.1.

@carmacleod
Copy link

Hopefully this PR will help by making the CORE-AAM mappings match the ARIA spec: w3c/core-aam#86

@stevefaulkner
Copy link

stevefaulkner commented Jan 28, 2021 •
edited
Loading

Is it not possible to make NVDA announce "has popup" without mentioning type at all? In this way at least when types other than menu are used the UI will not be incorrectly conveyed by NVDA.

@Wildebrew
Copy link
Author

Wildebrew commented Jan 28, 2021 via email

@khsbory
Copy link

khsbory commented Apr 22, 2021

@feerrenrut Hello. Regarding add aria-haspopup additional attribute in NVDA, is there any update?
Aria-1.2 spec also have these attributes such as dialog, grid and etc.
I think NVDA should consider to add these attributes.
Thank you.

@sarah-storm sarah-storm mentioned this issue Sep 7, 2022
Closed
@seanbudd seanbudd mentioned this issue Sep 20, 2022
Closed
@seanbudd seanbudd added p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. labels Sep 20, 2022
@Adriani90
Copy link
Collaborator

I must say I am not quite agreeing with a P4 on this issue. Web developers really want to follow the Aria spec in this regard, and if the result is not providing what it should, official compliance tests might fail. This burdens quite strongly on companies and institutions which really want to make things as accessible as possible. @seanbudd could you please consider this issue again internally at NV Access? I think it might not be that hard to implement a solution for NVDA in this regard, but I cannot really make an assumption on this. If possible, at least give us kind of an assumption on how difficult it would be to implement it.
cc: @michaelDCurran

@jcsteh jcsteh mentioned this issue Mar 8, 2023
Merged
6 tasks
@nvaccessAuto nvaccessAuto added this to the 2023.2 milestone Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ARIA p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Milestone
2023.2
Development

Successfully merging a pull request may close this issue.

Report aria-haspopup dialog/grid/list/tree in Firefox and Chrome. jcsteh/nvda