nvda
nvda copied to clipboard
nvaccess
NVDA does not recognize the ARIA 1.1 values of aria-haspopup
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.
Cannot reproduce with firefox 60 and latest NVDA master (Version: master-15089,482e916c) - reads as it should.
@Neurrone: Are you sure? It looks like most if not all buttons announce sub menu.
@leonardder my bad, didn't read the issue description carefully enough.
Can also reproduce.
@jcsteh: May be you could elaborate on what Mozilla is intending to do with the new aria 1.1 values of haspopup?
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. :)
@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.
I think there is a lot of value in users knowing when an element on the page will display a dialog when activated.
I've been doing a lot of end user testing with screen reader users lately, and I see that dialogs - even ones with appropriate ARIA markup - disorient them. But they are a necessary evil for the visual design, so we have to live with them. I think (at least hope) that setting the user expectations even from before the control is activated, may help screen reader users manage dialogs better. Obviously I do not know the NVDA code base so I can't tell how complex the implementation effort is, but on the surface it looks like a fairly small change. Of course I ultimately leave it up to you guys, I won't argue about it, not even for hours. grin
On 5/8/18, sasgrw [email protected] wrote:
@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.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-387529388
-- Work hard. Have fun. Make history.
@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?
I think a screen reader should simply report the verbatim values.
- Has dialog for dialog
- Has listbox for listbox (or has combobox to adjust to typical presentation)
- has tree for a tree
- has cgrid for a grid
- has menu or submenu for menu or true.
The most important thing, to my mind, is the dialog. At least it is the most common situation.
On 5/10/18, Leonard de Ruijter [email protected] wrote:
@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?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-388035686
-- Work hard. Have fun. Make history.
I think "has dialog", etc. is potentially confusing. How does it "have" a dialog? perhaps we could say "opens dialog"?
"opens a dialog" is much better wording than "as dialog", I totally agree. What about the existing wording for aria-haspopup="true", shouldn't it be changed to "opens a menu" if te other values are supported, to be consistent?
On 5/14/18, James Teh [email protected] wrote:
I think "has dialog", etc. is potentially confusing. How does it "have" a dialog? perhaps we could say "opens dialog"?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-388977836
-- Work hard. Have fun. Make history.
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.
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.
@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.
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.
@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.
I am primarily thinking about "opens dialog" for my test cases. The only grid widget that I deal with frequently is a datepicker, and I'd rather have the screen reader say "opens a datepicker" than "opens a grid". But if the ARIA group decided it was necessary to provide all these values I suppose those values should be supported to some extent by a screen reader. The logic behind some of the ARIA decisions (e.g. the tendency to add a lot of token values to attributes like aria-current and aria-haspopup) is a bit of a mystery to me (even if I participated in the working group for a short while), but maybe they see something I don't see.
On 5/7/19, Carolyn MacLeod [email protected] wrote:
@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.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-490270652
-- Work hard. Have fun. Make history.
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?
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.
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.
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.
Hi
If there are no plans to implement or if there are technical hurdles that make implementing support for this attribute impossible, can you please provide that feedback back to the ARIA working group? I am going to push for roles and attributes that have no implementation support 2 yars after being published to be deprecrated or removed, or at least revisited. Having the standard contain roles and attributes without any AT support is ultimately bad for accessibility.
On 11/27/20, Milan Turon [email protected] wrote:
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.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-734894856
-- Work hard. Have fun. Make history.
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.
Hopefully this PR will help by making the CORE-AAM mappings match the ARIA spec: https://github.com/w3c/core-aam/pull/86
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.
Why specify all those token values if screen readers are not announcing them? By far the most common form of popup on the web is a dialog, more so than "menus" (I strictly advocate using accordion/disclosure patterns for web menus, for ease of programming and better usability. I have to advise my team to use screen reader only text to announce dialogs, and I find it downright frustrating that I can't recommend using an attribute that has been in the spec for nearly 4 years due to near complete lack of AT support. This isn't just an NVDA issue, I know open source technologies, even great ones like NVDA are somewhat more restricted in how much they can support, but it applies to, I think, all screen readers.
On 1/28/21, Steve Faulkner [email protected] wrote:
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 aural UI will not be incorrectly conveyed by NVDA.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/8235#issuecomment-768982178
-- Work hard. Have fun. Make history.
@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.
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