On NVDA's ARIA Conformance with respect to collapsible and expandable states

[munawarb]

I'm working on making a site accessible to screen reader users, and one of the buttons, when clicked, opens up a menu of options.

The problem here is that I've found a few different supposed standard-compliant ways to convey the state of a button to a screen reader user, and this is where I'd like your advice.

There are two relevant attributes, aria-haspopup and aria-expanded. Both attributes do as their names suggest. The guides say to use aria-haspopup to convey that a button has a menu, and to add the aria-expanded attribute when the menu is expanded, and remove aria-expanded when the menu is collapsed or hidden.

However, I've only seen NVDA consistently convey the expanded/collapsed state of the menu in one instance: when I use only aria-expanded. Here is the code that works:

		function showOrHideMenu(sender) {
			const menu = document.getElementById(sender.getAttribute("aria-controls"));
				sender.setAttribute("aria-expanded", sender.getAttribute("aria-expanded")==="true"?"false":"true");
			if (menu.hasAttribute("hidden"))
				menu.removeAttribute("hidden");
			else
				menu.setAttribute("hidden", "");
		}

This code sets aria-expanded to "false" if it's "true" and "true" if it's "false". Then it either adds hidden="" to the menu or removes the hidden attribute, per html5 specifications.

<button id="userOptions" aria-expanded="false" aria-controls="userOptionsMenu" onclick="showOrHideMenu(this)">Extras</button>

Here, NVDA correctly announces "Button collapsed extras." When I click the button, NVDA correctly announces "Expanded." (Note: I'm not removing aria-expanded per the guide, because then NVDA won't announce the initial collapsed state of the button.)

Now, this is where things get interesting.

If I modify this code to conform to the standard, using aria-haspopup, my code looks like this:

<button id="userOptions" aria-haspopup="true" aria-expanded="false" aria-controls="userOptionsMenu" onclick="showOrHideMenu(this)">Extras</button>

Upon rendering this button, NVDA says "Menu button submenu Extras."

However, if I then click the button, activating the same Javascript that I had before of switching the expanded state to true, I get no announcement of expanded state.

Simply removing aria-haspopup allows NVDA to recognize the collapsed and expanded state of the button again, using no modification to the underlying Javascript.

Now, here's my question: what, exactly, is the standards-compliant way of achieving a collapsible / expandable button? One way works flawlessly with NVDA but doesn't include the aria-haspopup attribute. Is it noncompliant to remove the aria-haspopup attribute for a menu?

Second, why does NVDA fail to recognize the expanded / collapsed state of a button when including the aria-haspopup attribute?

I must say, this is my first time doing so much with ARIA and I'm disappointed by the liberal standards imposed on the specification. There doesn't seem to be one correct way to guarantee accessibility, even with NVDA which is the most compliant screen reader I know of. if I write this page strictly according to the spec from ARIA itself, NVDA won't report information correctly. Has anyone else faced this issue and what did you do about it?

[DrSooom]

@munawarb: Is it possible to use the HTML5 tags <details> and <summary> to do the same? And please test your code with different browsers as their rendering results/behaviors are different – sadly.
CC: @jcsteh and @MarcoZehe

[munawarb]

Hi @DrSooom, thanks, I didn't know about the summary and details tags. Indeed it does exactly what I was achieving through JS and I've rewritten that part of the code accordingly.

The behavior feels like the same behavior I get when removing the aria-haspopup attribute. For example, NVDA sees a collapsed button (rendered by the details tag) but doesn't announce a popup menu. At least now I can just leave it up to the accessibility APIs and NVDA's handling of the control instead of wondering if my pages are standards-compliant :).

Re: different browsers, in Chrome, NVDA does announce "submenu" and "collapsed" with the details tag, but in Firefox it just announces "collapsed." Either way, it is giving the relevant information (collapsed/expanded) in both cases now.

I'm still concerned that it fails so miserably with ARIA. We can't exactly expect sighted web developers to consider all of these variations in screen reader support for [Accessible]RIA. It feel like it's become a situation akin to "Well, you should follow access guidelines...but you also have to consider every screen reader's individual support for it." Something feels off about that to me. For instance, I have a feeling that were I to load these same pages with JAWS, I'd get a variation in accessibility support.

While this unfortunate variation of screen reader support is clearly noted in the ARIA specs, what's most concerning is NVDA's failure to announce the relevant state of a button when it's clearly marked with ARIA. Imagine if a sighted developer, who has no screen reader experience, comes across a guide on making an accessible menu and logically concludes that "I need to indicate haspopup and the expanded/collapsed state to give a screen reader the maximum amount of information possible." In Chrome (the browser I saw this problem in,) we'd end up with a bunch of buttons for which we can't tell their states. Not because the sighted web developer didn't conform to access standards, but rather because of our AT's poor support for the good standards the sighted developer followed.

[Adriani90]

also cc: @feerrenrut

[Adriani90]

in my view there should be a serious discussion between W3C and WHATWG, browser developers and screen reader developers regarding what is really needed and what should really be part of compliance tests etc. Then, a unified paper should be created where everyone agrees on the same target. It is really a mess to see how many ambiguous definitions are given and how many people are not well guided on how to create a really accessible website. It is really sad to see that browser developers and screen reader developers are doing different things when it comes to accessibility (see i.e. Firefox and Edge with NVDA and Narator). Actually everyone should sit at the same table and try to achieve some consistency regarding accessibility features.
At the end of the day, the screen reader user is the one who must cope with the result.

[brennanyoung]

At the very least, NVDA should do The Right Thing with this w3c example:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions-active-descendant.html
(At the moment, it does not announce the expanded state, unless you remove aria-haspopup, and even then it doesn't announce it consistently)

[brennanyoung]

Ah, just updated NVDA and now it announces 'expanded' but not 'collapsed' (using the w3c example I referred to in my previous post).

[jcsteh]

Ah, just updated NVDA and now it announces 'expanded' but not 'collapsed' (using the w3c example I referred to in my previous post).

That's because the W3C example doesn't set aria-expanded="false" when it's collapsed.

I'm testing with Firefox Nightly 2019-07-03 with NVDA alpha-17901,ac6ea147. With this URL:
data:text/html,<button aria-haspopup="true" aria-expanded="false">Test</button>
NVDA says "menu button collapsed sub menu test", which is the expected result. @munawarb, can you please re-test with this combination so we can be sure we're on the same page?

[brennanyoung]

That's because the W3C example doesn't set aria-expanded="false" when it's collapsed.

Should it? If so, we need to get the example changed!

[MarcoZehe]

That's because the W3C example doesn't set aria-expanded="false" when it's collapsed.

Should it? If so, we need to get the example changed!

Yes, IMO it should. If it is something that can be expanded and collapsed, both states should be present so the user knows that something is collapsed and thus can be expanded. If aria-expanded is not present, an extra state named expandable is not set. So, one state tells that something is expandable in the first place, and the actual state, true or false, is another state. And expandable is only present if the aria-expanded attribute is present and has a valid value.

[brennanyoung]

@MarcoZehe it seems like they did this on purpose 'to reduce chattiness' (apparently). Check this thread:
w3c/aria-practices#697

[MarcoZehe]

Well, then it appears as if we don't have a bug, right?

[munawarb]

@jcsteh, yes, it works as expected now. The collapsed state is properly announced even with haspopup. It works as well as using the summary tag.

@brennanyoung and @MarcoZehe, the example should set the aria-expanded attribute to false. An example here does this: https://www.w3.org/WAI/GL/wiki/Using_the_WAI-ARIA_aria-expanded_state_to_mark_expandable_and_collapsible_regions

I think the confusion here is whether or not aria-expanded should be set on the control if it's in a collapsed state. I would think yes, since the absence of the attribute (which usually denotes false with other attributes) leads to ambiguity for the screen reader: is this control collapsed, or is it not expandable at all?

The issue was that NVDA was not honoring aria-expanded=false when aria-haspopup was set, which is corrected in the latest alpha.

[Adriani90]

@munawarb thank you for your status update. As of now it seems we do not have a bug anymore here. I am closing this issue now as works for me. Please feel free to comment on it if it still occurs or you can open a new one if you like.