CUNY Academic Commons

I wanted to note other items- 510152-01, 510152-03, 510152-04 - which are about unordered-list semantics in the adminbar. This is another area where we are simply inheriting what WP uses, and I think we can probably push back against having to make mods.

Another family of issues worth pushing back on is the fact that the Toolbar markup is at the end of the document, so that WP uses a skip link rather than relying on natural tab order. See 510157-01

So I think we should push back on the idea that we need to rewrite the toolbar implementation to use the disclosure pattern. Instead, I think we should explain a bit of the background in WP itself, and then propose a couple modest improvements that we can shim on top of WP

I'm in agreement here. I noted the issues briefly in my initial outline, but if, and when, WordPress does do further accessibility improvements to the admin bar, we will inherit these improvements for free. Boone, your modest improvements will help, at least, placate some of the accessibility issues reported by Vispero.

Another family of issues worth pushing back on is the fact that the Toolbar markup is at the end of the document, so that WP uses a skip link rather than relying on natural tab order. See 510157-01

This should be addressed in https://github.com/cuny-academic-commons/cac/commit/7be2733e50. Adding the wp_body_open() function to the header template will now render the WP Toolbar at the top of the page. This also solves 510151-01 as the "Skip to toolbar" screen reader shortcut no longer shows up in the DOM.

Awesome - I didn't know that adding this function would move the toolbar in the DOM!!

I wanted to note other items- 510152-01, 510152-03, 510152-04 - which are about unordered-list semantics in the adminbar. This is another area where we are simply inheriting what WP uses, and I think we can probably push back against having to make mods.

I've removed the 'role' attribute for the mentioned HTML elements in the VPAT via JS in https://github.com/cuny-academic-commons/cac/commit/9a4a4ee875. When running various accessibility browser extensions after the commit, I do not see these role-related errors anymore.

More specifically, and perhaps more importantly for this specific issue, the review assumes that we intend to use a "button/disclosure" pattern here.

Disclosure pattern does match what the accessibility auditor likely saw when navigating through the WordPress admin bar. See https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/ for an example of the disclosure pattern when used in a navigation menu.

Based on the auditor's findings, I've implemented the disclosure pattern for our admin bar in https://github.com/cuny-academic-commons/cac/commit/ce491a8, https://github.com/cuny-academic-commons/cac/commit/c2d7bd8. It adds role="button" and aria-controls attributes to the links that toggle the submenu items and pressing the Space key on these links will toggle the visibility of the submenu. This is implemented in JS, rather than in the HTML markup.

Let's see what Vispero says after a second pass at our site, but Boone and Jeremy, if you feel that we should rollback the disclosure pattern changes, let me know.

Thanks so much for working on this, Ray.

It seems to me that this is much of the way toward meeting the criteria for the disclosure pattern (role=button, aria-expanded, aria-controls targets, keyboard support, etc). But there's still a semantic issue with the way that WP builds the admin bar, which is that the top-level dropdown triggers are a href rather than button elements. This means that clicking the items on desktop triggers navigation to another page as opposed to opening the submenu; on desktop, you hover in order to display the submenu. Obviously, this is upstream behavior and I don't think we should try rebuilding the way that WP builds menus. That being said, I do feel like the changes you made are genuine improvements and do genuinely mitigate some of the shortcomings of WP's implementation. So I think that we should keep them, but we should present the improvements to Vispero with this context.

I guess one thing we might consider, to make the implementation a bit closer to the spirit of the WCAG requirements, is to remove the WP hover/click behavior using some JS. So:
1. Remove the href from the top-level items (like My Groups)
2. Add a submenu item at the top of these submenus that say something like 'View All' and use the href that WP assigns natively to the top-level item
3. Juggle the event handlers so that hover no longer exposes the submenus - you need to click

We could do this without totally rewriting WP's menu implementation, and I think it would bring us closer to the spirit of the disclosure pattern. But it is a change in the current behavior: users familiar with WP, or those familiar with the Commons, could be surprised by the fact that hover no longer does anything, and that you need to click to expand. I don't love the idea of making this change, but I think it's worth keeping the idea in our back pocket in case Vispero pushes back that our mitigation causes activation confusion.

I guess one thing we might consider, to make the implementation a bit closer to the spirit of the WCAG requirements, is to remove the WP hover/click behavior using some JS.

I asked AI about whether using mouseover to open submenus for a disclosure menu is considered okay or not, and they said it is okay as long as the keyboard method of accessing the submenu still works and isn't impeded in any way. The main issue is what you mentioned here:

But there's still a semantic issue with the way that WP builds the admin bar, which is that the top-level dropdown triggers are a href rather than button elements.

Vispero might state the following (as they have used in several line items in the VPAT):

The presentation of two controls is not equivalent to the visual experience with a mouse, where only one control is conveyed. This disrupts the focus sequence for keyboard users, while for screen reader users it also creates the false impression of two potentially different controls.

AI recommended adding a click handler for these toggle links and using e.preventDefault() to avoid the click behavior and a similar keydown handler for the Enter key so it toggles the menu. This would make these toggle links act more like a button. I think this is something worth considering because if javascript is disabled, the href still acts as a decent fallback alternative. I think I'm going to go ahead with this, unless you have any other feedback, Boone or Jeremy.