Bug 23264 - OPAC elements with class="dropdown" include incomplete WAI-ARIA Menu
Summary: OPAC elements with class="dropdown" include incomplete WAI-ARIA Menu
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2019-07-03 23:25 UTC by Brian McNeilly
Modified: 2024-04-11 13:04 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian McNeilly 2019-07-03 23:25:33 UTC
Details:
Buttons that spawn items with role="menu" must indicate this fact with aria-haspopup="menu", and an aria-controls attribute referencing the id value for the element with role="menu". On expansion, focus should move to the first menu item, and focus should be tracked with either a roving tabindex attribute (so one menu item is always focusable) or tracked with an aria-activedescendant attribute on the element with role="menu". aria-expanded can be used to indicate the state of the button and its attached menu (e.g. expanded or collapsed).

This paradigm may apply to over OPAC menus, such as the Lists Menu on the homepage.

Steps to Reproduce:
1. Navigate to the element with id="langmenu"
2. Verify this item does not have an aria-haspopup attribute
3. Activate the element, verify a menu appears
4. Verify this content contains an element with role="menu"
5. Verify focus has not moved to the first menuitem beneath the menu
6. Use the arrow keys to adjust content within the menu
7. Verify tabindex attributes are not adjusted and aria-activedescendant is not set on the element with role="menu"

Actual Results:
Screen readers and other assistive technologies may be unable to interact with content as intended if ARIA controls are not coded to spec.

Expected Results:
The above listed attributes are added to the button item and element with role="menu". An example of a fully implemented button spawning an element with role="menu" (in this case using aria-activedescendant) can be found at: https://www.w3.org/TR/wai-aria-practices/examples/menu-button/menu-button-actions-active-descendant.html
Comment 1 Owen Leonard 2019-08-07 17:40:18 UTC
Brian I wonder if you could take a look at the demos of Bootstrap 4? The next upgrade of the Bootstrap framework in the OPAC will jump us to version 4.x I think. https://getbootstrap.com/docs/4.3/examples/ Bootstrap is the library that creates the dropdown menus.

I'm also curious if the same problem is found in the staff client, which is on Bootstrap 3.3.7. Thanks for investigating!
Comment 2 Brian McNeilly 2019-08-07 18:51:41 UTC
Checking an example from the Staff Client (the Logged In User dropdown), I am seeing the same issue outlined in the ticket. 

Bootstrap in 4.x appears to have removed adding any role information to their dropdowns. They include some basic ARIA requirements, such as aria-expanded. However, it appears they've added an invalid 'aria-haspopup' (https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup).

If the plan was to upgrade to 4.x for both the OAPC & Staff clients, this would effectively fix this issue. Though, I might suggest a few additional tweaks to improve the accessibility from what bootstrap already has. Off the top of my head the two things would be:
1. removing the aria-haspopup
2. adding a role of group to div class="dropdown-menu" (they seem to have removed the use of lists by default)
Comment 3 Henry Bolshaw 2020-10-13 20:43:46 UTC
Is this still an issue now that we have upgraded to Bootstrap 4 (bug 20168)?