Problem/Motivation

tb_megamenu level-1 'li' items are generated with the state:
aria-level="1"
According to SiteImprove, the accessibility tool used on our Drupal sites, aria-level is only a supported property of a 'div' with the "heading/comment/row" role. Having menus generated with aria-level attached to an 'li' will confuse ARIA reliant tools.

This is my first issue submission for Drupal! Yay. Please let me know how I can improve my submission and I'll help as much as I can.

Proposed resolution

Adding of aria-level to associated div with "heading" role. Removing aria-level from HTML elements that do not support the aria-level property.

Remaining tasks

CommentFileSizeAuthor
Capture.PNG66.75 KBapettine

Comments

apettine created an issue. See original summary.

emptyvoid’s picture

emptyvoid commented

I'm researching this bug for a client.

Reviewing the JavaScript the ability to mouse down to the next item in the menu is based on if the property topLevel is set. Reviewing the code, in mobile menu mode this fails and returns an empty array. There by defaulting to awaiting a tab down to hop to the next menu item.

As I've been told this isn't ARIA or Accessibility compliant at all.

In full screen desktop mode, it detects the menu and properly allows keyboard movement left and right, up and down between first live items. Researching how to debug the topLevel function to properly read menus in mobile state.

frontend.js
line 133

emptyvoid’s picture

emptyvoid commented

FYI issued a patch fixing this bug in the 2.x-alpha

https://www.drupal.org/project/tb_megamenu/issues/3316164

Please enjoy.

apettine’s picture

apettine commented

Thank you for the heads-up and your time; I look forward to seeing the change in 2.x-alpha.

cosipa_a11y’s picture

cosipa_a11y commented

In the current ARIA 1.2 standard, aria-level is supported on elements the listitem role (e.g. <li> elements), but in practice there's not much browser / screen reader support for this configuration. Both JAWS and NVDA ignore these attributes.

It's worth noting that in the upcoming ARIA 1.3 spec, support for the listitem role has been removed from aria-expanded.

rbrownell’s picture

rbrownell
he/him
Primary language English
Location Gatineau, Québec, Canada
commented
Status: Active » Postponed
Related issues: +#3316164: Mobile Keyboard broken
rbrownell’s picture

rbrownell
he/him
Primary language English
Location Gatineau, Québec, Canada
commented
Status: Postponed » Closed (won't fix)

Thank you for raising this and for the detailed discussion around ARIA roles and expectations.

After reviewing this more closely, I’m going to close this issue. The behaviour described here is not a violation of the currently published ARIA specification (ARIA 1.2). The concerns raised align with changes introduced in ARIA 1.3, however that specification is still in draft and is not yet an official recommendation.

TB Mega Menu’s implementation for the affected branch aligns with ARIA 1.2, which is the applicable standard at this time. This issue also targets an older release that is now only receiving security updates.

Once ARIA 1.3 is finalized, any required changes would be addressed in the latest supported development versions only, and not backported to branches that are in security-fixes-only mode.

For these reasons, this is not considered a bug under the current standard and the issue is being closed.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.