Accessibility of the administration menu (submenus) on the left hand side

[reetagithub]

Describe the bug
I tried to handle the DSpace demo at https://demo7.dspace.org/ with a screen reader. I registered with userid [email protected] and got the navigation bar present at the left hand side. The screen reader I used was Apple's VoiceOver, and there were problems.

All the menu items were not available. I could open menu item 'Access Control' but I did not get to its contents ('People', 'Groups'). Hence, I cannot find my way from the menu to the page in question - I do not know how to get to the page 'Groups'. I know that I am not as capable with screen readers as for instance people with visual impairment, but I think this is a problem in the DSpace.

I am sure you are aware of the legislation in Europe: accessibility is mandatory.

To Reproduce
Steps to reproduce the behavior:

1. Log in to DSpace
2. Activate screenreader
3. Go through the administration menu on the left hand side

Expected behavior
All the menu items should be read by the screen reader. All the manu items that can be clicked with a mouse can be selected using the screen reader. After selection, focus moves to the opened page.

Related work

[tdonohue]

@reetagithub : Thanks for reporting this issue. Did you see any indication of what may be wrong with the Administrative menu's structure to cause this behavior?

The reason I ask is that we have been using automated accessibility scanning tools (like Deque's Axe Devtools plugin) in order to scan all our pages for accessibility issues. I just tried running that scanner against our Administrative menu, and it didn't detect any accessibility issues.

Obviously, though, we realize that an automated scanner like this may not be able to catch 100% of all problems. So, I was just trying to narrow down what the issue may be with the admin side menu, so that we can find a quick fix.

We do realize that accessibility is a high priority. But, in this scenario, it appears our current tools are failing to tell us the source of the issue, which is important to help us determine the proper fix.

[tdonohue]

@reetagithub : Did some more testing with additional tools, and I think I've found the issue after all. It's also detectable with the Axe Devtools plugin, but only if the entire menu of options is expanded.

The problem appears to be that the submenus have "nested interactive controls" which can confuse some screen readers: https://dequeuniversity.com/rules/axe/4.6/nested-interactive

I think the core issue is that, while the main menu itself is correctly marked up with ARIA controls, etc... the submenus appear to have incorrect ARIA / role attributes. The submenus all are marked up as either role=button or simply <a> tags... but, I think they are supposed to be role=menuitem under a role=menu similar to the pattern described here: https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

So, I think this is definitely a bug we hadn't discovered in the submenu accessibility. I'll pull this over to the 7.6 board and see if we can locate a volunteer to help correct these submenus to have better ARIA controls.

[tdonohue]

Looked into this a bit more, and it looks like the accidental result of other accessibility fixes applied in #1295 by @ybnd .

That PR made this side menu much more accessible then previously... but, it accidentally created a new problem where the dynamically built sidebar menu is structured like this (I've left out a lot of the code for brevity and to show the core problem):

<div class="sidebar-section">
  <!-- NOTICE the role=button on this surrounding div-->
  <div class="nav-item .." role="button">
    <div class="shortcut-icon">
       <!-- Icon displayed here -->
    </div>
    <div class="sidebar-collapsible">
       <div class="toggle">
           <!--Menu name displayed here in a span-->
       </div>
        <!-- Submenu displayed in a ul --> 
       <ul class="sidebar-sub-level-items">
           <li>
               <a><!-- Each submenu links displayed here.  NOTICE this link is a child of a "role=button" --></a>
           </li>
       </ul>
    </div>
  </div>
</div>

In case it's not obvious, the core issue here is that there is a link (<a>) embedded as a child of a button (<div role="button">). This results in the "nested interactive controls" error from accessibility scanning. You cannot embed a button or link inside another button or link.

It appears we'll need to restructure this code so that the button which opens the submenu doesn't surround the entire submenu. Needs a volunteer, as I don't know that I'll have time to dig further...but hopefully that's enough information for someone else to easily pick this up and solve it.

[reetagithub]

Sorry for the delay, Tim, I has on spring vacation. I am glad that you found the answer, I would not have been able to give any more details. However, it is known that static tools such as Wave do not tell everything, but real testing / audit with screenreaders should be made as well.

[davide-negretti]

#2676 is going to solve these issues. I tested header and navigation menus with these Chrome extension, and admin sidebar seems to work fine.

https://chromewebstore.google.com/detail/silktide-accessibility-ch/mpobacholfblmnpnfbiomjkecoojakah

https://chromewebstore.google.com/detail/aria-devtools/dneemiigcbbgbdjlcdjjnianlikimpck

https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh

[tdonohue]

Ported to 7.x in #2858