NVDA is not reading expanded/collapsed on button with aria-haspopup as "true"

[myr-account]

Steps to reproduce:

1. open the link and on the NVDA in chrome browser
2. tab till "click here" button
3. click to "inspect element" on the button
4. now try to toggle the button, we can see that aria-expanded property is not read by [NVDA] (url button_exp_col.txt)

Actual behavior:

NVDA is not reading "aria-expanded" property as expanded or collapsed on toggling the button

Expected behavior:

NVDA must read "aria-expanded" property as expanded or collapsed on toggling the button

System configuration:

win 10, 64-bit operating system, 16GB RAM

NVDA installed/portable/running from source:

Installed on system

NVDA version:

2018.4

Windows version:

Chrome Version 71.0.3578.98 (Official Build) (64-bit)

Name and version of other software in use when reproducing the issue:

NA

Other information about your system:

NA

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

[LeonarddeR]

This works in Firefox 65 beta 5. cc @derekriemer

[brennanyoung]

I'm still seeing this issue on (for example) the w3c example here

[divyanshumehta]

@leonardder Facing this issue in chrome till now.

[Adriani90]

If I understand this correctly, the string "expanded" or "colapsed" is sent to the screen reader via aria has popup. This popup is interupted by the focus event, the focus jumps to the menu item. @feerrenrut is it possible to solve this in the speech manager? Let's say to give the aria has popup priority over the reporting of focused element?

cc: @ObjectInSpace

[Adriani90]

It seems if Firefox this is working as expected. But in borth browsers, the status "colapsed" is not reported when colapsing the menu.

[ObjectInSpace]

It only reads "expanded" in Firefox if focus mode is on. I also notice that the state of the button is not read when reviewing it in either browser. Shouldn't it say if the menu is collapsed or expanded when the button is focused?

[Adriani90]

it seems NVDA reports "expanded" when the button is expanded and you focus it with arrow keys. But this does not work when the button is colapsed. NVDA does not report it, for what ever reason. Neither when focussing, nor when pressing enter on the button.

[RichCaloggero]

The reason the state of the menu isn't read when the menu is collapsed on either of the following two w3C example pages is because when the menu is collapsed, they remove the aria-expanded attribute altogether. This is an authoring error.

• https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions-active-descendant.html
• https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions.html

-- Rich

[brennanyoung]

This is not an authoring error. w3c docs specifically recommend removing the attribute when the menu is hidden/collapsed.

See here: https://github.com/w3c/aria-practices/issues/1318#issuecomment-581487936

[aritse]

On an element with either "listbox" or "combobox" role, I expect the screen reader to announce "expanded" or "collapsed" depending on the value of the aria-expanded attribute.

[Adriani90]

Now it seems the Expanded status is reported correctly every time in last NVDA Alpha. Still the colapsed status is not reported.

[d-kacprzak]

I confirm that the problem still exists.

[tavisca-dpingale]

Was facing similar issue on chrome after adding role button fixed the issue on chrome. now it reads expanded collapsed on chrome

[lupuovidiul]

on chrome it is ok now, but on firefox the problem still persists. Does anyone have a workaround for this?

[e111077]

The same issues are happening on Chrome in the W3C's combobox examples here:

https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html

Should I file a different issue for combobox or is adding onto this bug the same underlying issue?

[feerrenrut]

This issue is not very clear. In future please copy the exact speech that hear (use speech viewer to help) and paste under the title "actual behavior". Then you can edit this for the "expected behavior".

When using the W3C example: Pressing tab to get to the "Actions" NVDA speaks:

Actions menu button subMenu

Then pressing "enter" to open the menu, NVDA speaks:

Action 1 1 of 4

Then pressing "esc" to close the menu, NVDA speaks:

Actions menu button subMenu

Maybe this output from NVDA can be more clear, however I want to note that a screen reader should not simply report all aria attributes to the user. NVDA needs to present as complete as possible information to the user, while minimizing verbosity. Let me break down each of these steps:

• The text in this example already says "menu" and "subMenu" which seems redundant to me.
• When the menu is expanded, the first item has focus "Action 1", reporting that the menu is expanded seems irrelevant and redundant. Since the button no longer has focus when the menu is expanded, use object navigation to read the button without affecting system focus, NVDA speaks: "Actions menu button expanded subMenu".
• When the menu is collapsed the absence of "expanded" tells us that it is collapsed, however we still know it is a menu.

I'm happy to discuss this further, and I'm certainly willing to look at ways this can be improved, but please be very clear with your descriptions of behavior, and ideally also tell us why you think it should change.

[e111077]

Again please let me know if this should necessitate its own issue.

For the case of combobox with has-popup announcing expanded / collapsed:

Steps to Reproduce:

1. Open W3C aria example (link)
2. focus the second example
3. type the letter "a" to expand the combobox
4. type the letter "z" to expand the combobox

Actual Behavior

on focus: "Main landmark, combobox collapsed, choice 2 fruit or vegetable, edit, has autocomplete, blank"

on typing "a": "a"

on typing "z": "z"

Expected Behavior

on focus: "Main landmark, combobox collapsed, choice 2 fruit or vegetable, edit, has autocomplete, blank"

on typing "a": "a, combobox expanded"

or

"a, autocomplete has 3 suggestions, <perhaps instructions on navigating the combobox?>"

on typing "z": "z, combobox collapsed"

or

"z, autocomplete has 0 suggestions"

Reasoning

Granted NVDA will mention that there is a collapsed combobox and it is an autocomplete, but there is no indication of whether to navigate down or not as the user continues to type. If the user does press down after az, which has no suggestions, then it will simply announce "az" and "spelling error".

If the user were to type apple then it would announce "a,p,p,l,e" then pressing down announces nothing. There's no feedback that it is a selectable item in the combobox as there was no indication of the combobox expanded state

[feerrenrut]

Thanks for the clear write up @e111077. I think your comment would indeed be better as a new issue.

[FashionGod]

If I added child element with combobox in aria-control container, then the 'collapsed' and 'expanded' will not announced. If I removed the child element it work. such as this child element <ul class="options" id="filter-select-author-options" role="listbox"><li role="option" data-value="*" class="selected" aria-selected="true">All</li></ul> Dose anyone meet before? plz help. which weird is when I removed the attribute such as role="listbox" etc. it dosen't work. but when I removed the element, it works fine.

[FashionGod]

As a supplement to the previous comment. I tried Firefox version 105.0.3(64-bit) expanded and collapsed announced normal. but in Chrome version 106.0.5249.103(Official Build) (64-bit) expanded and collapsed announced fail.

[VivianSi233]

We find a bug which repro on M365-SCC Page Templates ⋅ subcomponents/CommandBarItem/DropdownControl - Default (scc-storybook.azurewebsites.net). When open NVDA speech viewer, expanded displays on speech viewer when activate drop down control. But 'expanded' is too fast to hear from headphone, user only hear Item1 checked 1 of 4 clearly.

I am not sure whether it is the same root cause of this bug, please help to investigate. If you think we need to log a new bug for this scenario, please let me know, thanks.

[feerrenrut]

@VivianSi233 Please open a new issue following the template, it will be important to include a minimal sample and steps to reproduce as required by the issue template.

[JaiRai0304]

Do we have any update on this issue? It seems the issue still exists. I was testing this menubar example at w3c website: https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/

Below screenshot has my finding with NVDA+ Chrome. Although the aria-expanded attribute is present , but NVDA not announcing the collapsed state.

However the voiceover(MacOS) is announcing it as "About , collapsed, menu item" which looks good.

[Adriani90]

@JaiRai0304 note that here are a lot of blind developers. We need the screenshot as a plain text so we can read it with the screen reader. I try to explain my findings: It seems not consistent between browsers, but I cannot reproduce in Chromium. I guess the root cause might be the same like for combo boxes and possibly other controls.

Firefox > NVDA browse mode:

1. Pressing enter on menu item, NVDA does report expanded or colapsed on the first attempt, after that NVDA does only report "menu" when expanded, and is silent when colapsing the menu.
2. Last menu item "academics" redirects the focus to a submenu item,. In this case NVDA does not report the status colapsed or expanded, which is acceptable from an user perspective since you no already that NVDA will move the focus to a sub menu item so you know that this means the menu is expanded. The focus moves back to the parent menu item when colapsing, so it does not need extra reporting.

• Expected behavior: for part 1, NVDA should report expanded and colapsed on the menu items with submenu which do not redirect the focus to a submenu item, same as it does in Chrome and Edge.
• In general NVDA should report expanded and colapsed on controls that have this role and do not redirect the focus.

firefox > NVDA focus mode:

1. Parent Menu items with sub menu are colapsed when pressing right arrow,, expand automatically when pressing down arrow, enter or space bar; and colaps automatically when pressing escape. This is similar to the ribbon structure in Microsoft office, from an user perspective it is acceptable and does not need the reporting of expanded or colapsed.
2. Child menuitems with submenu are expanded when pressing right arrow, enter or space bar; and colapsed when pressing left arrow or escape. This is consistent with most sub menus in Windows, see for example the NVDA menu. This is also acceptable from an user perspective and does not need reporting of "expanded or colapsed".
3. In Firefox, NVDA does not count the number of items correctly. When I expant the menu item "academics" which contains 8 submenu items, NVDA says "1 of 4" and the counting starts again at 1 on the fifth element. While this could cause confusions, it is a different issue and is not in this scope of this one.

• Expected: NVDA should count the correct number of menu items, like it does in Chromium.

Chromium > NVDA browse mode:

1. NVDA reports on all menu items "expanded" or "colapsed" no matter how often I press enter on the menu items, except for the last menu item "academics" which redirects the focus (see above).

Chromiuim focus mode:

1. NVDA behaves like in Firefox, but here NVDA reports the correct number of submenu items, no issue here.

cc: @jcsteh could you have a look at the Firefox part? There might be already bugs filled for that in Bugzilla.

[JaiRai0304]

hi @Adriani90 - Thanks for your review, and In future I will add screenshots as plain text.

I tested with NVDA version 2021, and NVDA version 2023 on chrome browser. In focus mode, when i am landing to menuitems, NVDA not announcing the collapsed state of the menuitems. For me it's announcing as " About Submenu 2 of 4" .

[Adriani90]

That is expected behavior and is consistent with all menus with submenus in Windows. For this menu submenu case there is no need to report colapsed or expanded when focussing it, but Only when performing the action and not redirecting focus.Von meinem iPhone gesendetAm 05.04.2023 um 09:32 schrieb Jai Prakash Rai @.***>: hi @Adriani90 - Thanks for your review, and In future I will add screenshots as plain text. I tested with NVDA version 2021, and NVDA version 2023 on chrome browser. In focus mode, when i am landing to menuitems, NVDA not announcing the collapsed state of the menuitems. For me it's announcing as " About Submenu 2 of 4" .

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[jcsteh]

Firefox > NVDA browse mode:

1. Pressing enter on menu item, NVDA does report expanded or colapsed on the first attempt, after that NVDA does only report "menu" when expanded, and is silent when colapsing the menu.

What I would expect here is that NVDA always reports "menu" and switches to focus mode when the menu is expanded. That is, focus should be redirected to the menu if it isn't redirected elsewhere by the web page. Chrome doesn't ever seem to do this, though, and Firefox is inconsistent. I'm not sure why yet, nor am I sure why Chrome is deviating here. I'll look into it.

NVDA intentionally doesn't report collapsed on a menu item which has a sub-menu because you normally reach such menu items with focus and you can't reach menu items with focus unless they're collapsed. This makes the collapsed/expanded state redundant.

3. In Firefox, NVDA does not count the number of items correctly. When I expant the menu item "academics" which contains 8 submenu items, NVDA says "1 of 4" and the counting starts again at 1 on the fifth element. While this could cause confusions, it is a different issue and is not in this scope of this one.

The menu contains a separator between the two groups of items. Firefox considers separators when counting, stopping when it reaches a separator. Without this, users wouldn't be able to tell that there are two separated groups of items.

[XLTechie]

@jcsteh

The menu contains a separator between the two groups of items. Firefox considers separators when counting, stopping when it reaches a separator. Without this, users wouldn't be able to tell that there are two separated groups of items.

Can we report something like "1 of 4 in group" under these circumstances? Or "1 of 4 in first group", "1 of 4 in second group" . . .

[Adriani90]

I am not sure if I should open a new issue regarding the count elements in group of elements with separators. Actually NVDA does not report that this is a group of elements.

Separators can have a label, but since they are not focusable in focus mode I am not sure NVDA would report that label though.

I found an interesting discussion here which recommends rather using the group role with a label instead of separator labels. In any case, i think a combination of separators and group roles would make obvious for users that there are group of elements and how many elements are in each group. This is in the responsibility of the web author to use them correctly. https://github.com/w3c/aria-practices/issues/614

[msftedad]

Hi team, Any update on this issue?