Page MenuHomePhabricator

Headers of collapsible (sub)menus in sidebar not accesible via keyboard
Closed, ResolvedPublic


Headers of collapsible (sub)menus in sidebar (This feature is available on Commons only currently.) are not accesible via keyboard.

One can not expand the submenu and access its items.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:08 PM
bzimport set Reference to bz23428.

This is resolved in r66029. Thanks for the excellent report!

maria.schiewe wrote:

While this now allows users to collapse the menu, it still is not clear to the user that he can do so. The element is still a heading level 5. No screenreader user will suspect that he can interact with the heading to collapse a menu. You must either insert some text indicating the possibility and/or use other elements that are known to the user for interaction, i.e. a link, or set the clickable attribute.

This is a bug in screenreader software in my opinion. The onclick html attribute should be avoided in favor of DOM hooks. If the screenreader software then doesn't see it as a clickable element, then the screenreader software really ought to be improved.

Not saying that it doesn't affect accessibility, just saying that screenreader software producers have a responsibility as well here....

maria.schiewe wrote:

I don’t agree that this is a bug in the assistive technology. How should a screenreader recognize that the h5 can be interacted with? By inspecting all of the associated Javascript code? Hardly feasible. Here a non-interaction element (h5) is used to build some interaction. That is no good style, the element is misued. WAI-ARIA mark-up would offer a solution but isn’t supported by all screenreaders yet—and not by older versions.

It's not a perfect world. I agree that it is HARD to do for assistive technology, but that IS where it primarily should be fixed. And it will, because the web is getting more interactive by the day. The idea that only interactive elements are capable of interaction is getting quickly outdated.

Now to get back on solving this. Adding a <a> element inside the <h5> ?

maria.schiewe wrote:

It will be fixed by “perfect world” programmers enhancing their code with WAI-ARIA, because to interact with an element you must know it’s interactive. *smile*

As for the solution, yes, I think adding an <a> inside the <h5> will solve the problem. Still it would be neat to have an indication about the collapsing. Normally, one could do this over the alternative text of the image, but here we have a background image that can have no alternative text.

  • Bug 24582 has been marked as a duplicate of this bug. ***

The Actions menu has the same problem. Suggest using <a> with a title attribute. (without a title element, some [VoiceOver] will repeat the title of the current page).

  • This bug has been marked as a duplicate of bug 24298 ***