Nvda: Speech is cancelled in browsers when encountering a menu, menubar, or menuitem

[mpreyskurantov]

Use the following HTML markup to reproduce the issue:

<div role="application" aria-label="Horizontal menubar">
    <div role="menubar">
        <a href="#" role="menuitem">Item 1</a>
        <a href="#" role="menuitem">Item 2</a>
    </div>
</div>

NVDA reads this markup in the following manner:

Item 1
Item 2

The expected pronounced state is the following:

Horizontal menubar
Item 1
Item 2

While the speech viewer tracks the aria-label="Horizontal menubar" word to its log, it does not pronounce it. Note that NVDA in Firefox does not have this issue.

[bhavyashah]

@mpreyskurantov Could you please mention the version of Internet Explorer in use while experiencing this issue? Also, please test the same with NVDA 2017.3 and let us know in case there are any changes in the testing results. Also, it may be helpful if you could attach a test HTML document demonstrating the reported problem instead of only providing the relevant HTML markup.

[Raushen]

Hello, @bhavyashah

I have tested this issue under a newer NVDA 2017.3 on IE 11.0.9600.18739, and it still does not work as expected.
You can check how it works on my video (with sound) via the following link:
https://monosnap.com/file/MEg24FnPnjFJpbFlTUD8b0bhYOuoik
Moreover, I have also noticed that it is now broken on FF 55.0.2.
Please find the full test html page in the attachment.
NVDAApplicationRole.zip

[andrewleith]

This also doesnt work for me in IE 11/NVDA 2017.3, although the exact same markup does work in Chrome 61.0.3163.100. Seems like a pretty important attribute to have working!

[andrewleith]

Aria-labelledby seems to work just fine. I must say it is extremely challenging to have to try and work around screen reader bugs.

From the point of view of the developers of screen reader software, what is your advice on that front? Is a product accessible if it meets the WCAG guidelines but the screen reader software doesnt work anyway?

[feerrenrut]

@andrewleith are you suggesting that aria-labelledby is a viable workaround for this? Can you link to the guidelines you refer to please?

It should be noted that in the video, "Horizontal menubar" can be seen in speechviewer but not heard. @Raushen in case you are not aware, the majority of NVDA developers are blind, and would not be able to watch that video.

[andrewleith]

@feerrenrut: here I'm less interested in the exact wording of the guidelines and more interested in the behaviour of the screen reader software (since the two often do not jive). In general, the guidelines say that form fields need to be identified by labels (https://www.w3.org/TR/WCAG20-TECHS/H44.html) so that is my goal. In this case, I'm using an enhanced dropdown menu which doesn't use an actual form control (it uses a div instead of a select)

More explicitly, https://www.w3.org/TR/WCAG20-TECHS/ARIA14.html, https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html, and https://www.w3.org/TR/WCAG20-TECHS/ARIA16.html suggest that the use of aria-label and aria-labelledby for labelling "non-text content" is legitimate.

Remember, these type of guidelines exist just to make sure that a user of assistive technologies gets the same context as a sighted user. That is the sole desired outcome.

My goal when testing for accessibility is that all of the visual information that is displayed to sighted users (i.e. labels, descriptions, etc.) is presented to every user in a way that makes sense logically. In this case, when the user tabs to my enhanced dropdown menu, I want a particular label to be read, and aria-labelledby seems to do do this reliably with NVDA in the browsers I've tested. In this context I don't really care what WCAG says because if the user isn't alerted to what the control does, it really doesn't matter.

All that being said, its a shame how much extra effort is required to make certain combinations of techniques work with various combinations of screen reader and browsers. My initial solution of using aria-label worked just fine in VoiceOver with chrome and safari. It even worked fine with NVDA and chrome. It wasn't until I started testing with NVDA and IE that I realized it wasnt working. Which lead me to my question above:

is a web site accessible if it meets the WCAG guidelines but the screen reader software doesnt work anyway?

[feerrenrut]

Thanks @andrewleith. It is indeed frustrating when there are differences between browser behaviour, and of course this can be amplified by the AT operating on top of this. I would say, no the website is not accessible just by meeting the guidelines. The website a11y developer relies on the AT and the browser, the AT relies on the browser and the OS, standards non-conformance due to a mistake or non implementation at any of these layers can cause difficulties for those operating at layers above. If the goal is to produce accessible sites, then these issues need to be worked around, however frustrating that is.

Using NVDA version next-14535,3aad54e0
@Raushen looking at your NVDAApplicationRole.zip example in IE Version: 11.674.15063.0 Update Versions: 11.0.47 (KB4040685) . You didn't explain how you were moving through the elements. If I move through the elements with the Tab key I get the following:
button Browse mode press tab
Focus mode Horizontal menubar Item 1 press tab (Note: Horizontal menubar is not heard, only shown in speech viewer)
Item 2 press tab
button Browse mode button

The likely reason for horizontal menubar showing in speech viewer, and not being heard is that NVDA cancels speech when encountering a menuitem. Using tab to move through the elements means that focus jumps straight to the menu item link.

When moving through this example using the down arrow I get the following output:
Browse mode button press down arrow
application Horizontal menubar (this is shown in speech viewer and heard) press enter to activate the application
Horizontal menubar Focus mode Horizontal menubar Item 1 (only Item 1 is heard, again because speech is canceled on menuitem)

I seem to get the same behaviour in Firefox 55.0.3 (32-bit) and 56.0.1 (64-bit)

Perhaps not relevant to the issue being explored, but using role=application for this outside div seems unnecessary here. I will also note that if some other content is added to this div for focus to land on before the menu item, then the speech is not cancelled.

Edit: Added the version of NVDA I used for testing.

[Raushen]

Hello @feerrenrut,
Let me clarify the complexity of this issue in greater detail.
We have a task to make our Menu control work in the following scenarios:

• Support for navigation with arrow keys;
• NVDA support;
• JAWS support;
• It should meet all the Section 508/WCAG 2.0/WAI-ARIA 1.1/HTML5 standards;
• It should pass the WCAG and Section 508 audit.
  Regarding the audit:
  Experts that are involved in this task perform audit using screen readers' Focus-mode. So, it's critical for us to support this mode. Yes, we use the Tab key for navigation in this sample.
  To accomplish our task, we researched the WAI-ARIA standard and found the necessary attributes. According to the standard, the following markup should work fine:
   

<div role="menubar" aria-label="Horizontal">
    <a href="#" role="menuitem">Item 1</a>
    <a href="#" role="menuitem">Item 2</a>
</div>

 
However, this markup is not supported by NVDA:
The aria-label attribute is not pronounced even in Browse-mode in FireFox. So, an end-user cannot check which arrows are used for navigation (up-down or left-right).
Then, we tried to use the following markup:
 

<div role="application" aria-label="Horizontal menubar">
    <div role="menubar">
        <a href="#" role="menuitem">Item 1</a>
        <a href="#" role="menuitem">Item 2</a>
    </div>
</div>

 
We assumed that a screenreader cannot ignore the aria-label attribute of an element with the "application" role, because this attribute contains information about a navigation way and element assignment. This markup works perfectly in JAWS and operated in NVDA (the FireFox browser), but currently NVDA doesn't pronounce this attribute. We created this bug and are looking for a workaround.
 
When the aria-labelledby attribute is used, it is necessary to create additional HTML elements, which is not preferable in our case. Our current markup is the following:
 

<div role="menubar">
    <a href="#" role="menuitem" aria-label="Horizontal menubar">Item 1</a>
    <a href="#" role="menuitem">Item 2</a>
</div>

 
We have to change the aria-label attribute of the element dynamically when it gets focus. Resolving this issue will significantly simplify our current approach.

[andrewleith]

@Raushen, it may be because there is no tab stop on your role="application" div. If you are using tab to navigate, this means you will bypass that element and go straight to the first a element.

Have you tried this:

<div role="application" aria-label="Horizontal menubar" tabIndex="0">
    <div role="menubar">
        <a href="#" role="menuitem">Item 1</a>
        <a href="#" role="menuitem">Item 2</a>
    </div>
</div>

[feerrenrut]

We can agree that it's annoying that the aria-label speech is cancelled when the NVDA encounters a menu item, especially if valuable context is given in the label. In this case (menuitems in a web browser) there is less chance of being too verbose (than say in a windows application). I will give this a priority 3 to change the behaviour in this way (not cancel speech when encountering a menu / menubar / menuitem)

I don't know if the examples given are realistic, or true to how you are actually using them. But can I suggest that "horizontal menubar" does not give much/any information to a blind user. If this were "account menu" for items such as logout, preferences, etc, then it would be providing useful information.

[Adriani90]

cc: @jcsteh

[jcsteh]

NVDA cancelling speech for menu bars and menus is deliberate, if not ideal in all cases. See https://github.com/nvaccess/nvda/issues/4278#issuecomment-155322023 for an explanation. The reality is that in the majority of cases, hearing the menu bar or the menu creates extra verbosity without adding any value whatsoever for the user. However, I agree it's theoretically possible for value to be added. The challenge is coming up with a way to distinguish the minority cases where value is added from the majority cases where it isn't and then altering the behaviour accordingly.

[Adriani90]

Closing as fixed by #11190.