Accessibility of Main toolbar items and internal editing

Hey Kevin, this might be more than one bug report and there might already be an issue open for this. I'm not 100% sure.

A screen capture would be great (even just the HTML that you want changed). Helps us dig down and make sure it is in the right place.

I'm bumping this down to Major until we get a bit more information on it.

Major is the correct status for this.

This issue is a bit unclear. There's quite a bit of detail, but I think it's describing several distinct issues. These can be addressed individually.

Using the tab key on the top level toolbars resulted in jumping over important navigation items.

It's not clear if you're using the toolbar provided by Drupal core, or the admin toolbar module from contrib. I suspect this part refers to the extra behaviour from the contrib module.

The toolbar provided by Drupal core has two orientation modes:

• In the horizontal orientation, only top-level links are included. All admin pages in Drupal core can be accessed by using a top-level link, then using links on the landing page.
• In the vertical orientation, the admin toolbar allows access to nested pages. There are buttons to expand collapse some sections of the menu tree. For example, the "structure" top-level link is followed by a button called "extend structure" which discloses the second level links. It could be improved by making proper use of aria-expanded and aria-controls properties. Currently the button conveys it's expanded/collapsed state by changing the text on the button. In this example, the button name changes from "extend structure" to "collapse structure". I will open a separate issue to address this.

The admin toolbar contrib module adds drop-down sub-menus to the toolbar when it is in horizontal mode. These work with mouse hover but don't have good accessibility the last time I checked. There is a proposal to bring some of the contrib module's features into Drupal core. It will need to have an accessibility plan to do so. The contrib module is included with some Drupal distros.

When editing and managing content, each page header has an ‘open configuration options’ toggle button. These buttons make no sense when accessed out of context with either the tab key or JAWS forms fields list. For example, "Edit" has no Aria- describedby / labelledby (x) value to help with context or aria-live to explain what is happening dynamically when you edit.

This refers to the buttons from contextual links module, most likely. These aren't part of the toolbar. They are actually scattered all over the page, and represent shortcuts to various other admin pages. Typically each "block" has one of these buttons.

You're correct that some of these have no context and can't be distinguished. Some of them do have informative names though. For example, the contextual menu button next to the search block is called "Open Search configuration options". Drupal core is quite inconsistent here, so we should address this. In fact I think there is already an open issue about it. If not, I'll open one.

These contextual links buttons do make use of aria-pressed, but this isn't the most appropriate ARIA state to use. It would be better to use aria-expanded and aria-controls to convey the behaviour of these buttons. I'll open a separate issue about that, because it's separate from any issue to do with the toolbar.

Aside: I've started a plan to address a bunch of accessibility issues in the Drupal core toolbar as a whole, in #3084529: [META] improve accessibility of toolbar. Linking this one as a related issue which needs more investigation. I will gather all the issues raised here under that parent issue.

Note to self: this one could do with a better title.

@andrewmacpherson: Maybe I can add some clarification to this issue. I tested it using keyboard tabbing and VoiceOver on Mac as I don't have JAWS installed on my Windows laptop. I was able to tab through to the shortcuts submenu items without an issue, although as mentioned it does need to have aria-expanded added to it to inform the screen reader user of its state.

However when I viewed the links within the rotor (Ctrl+Option+U) I could see the Shortcuts link but not the submenu links. I think that's at least partially what the OP is referring to. Those links should be showing up in that list and I'm not sure why they aren't.

I don't think that aria-controls will affect it as it's only modestly supported by screen readers. I'll look into it further as well, but I hope that this info clears things up a bit.

-Kat

However when I viewed the links within the rotor (Ctrl+Option+U) I could see the Shortcuts link but not the submenu links. I think that's at least partially what the OP is referring to. Those links should be showing up in that list and I'm not sure why they aren't.

That's by design. There is only one second-level tray of links visible at once, and the others are hidden by CSS display:none;. These won't appear in the list of links in VO rotor, or the equivalent tools in JAWS and NVDA. For links to appear in the VO rotor list, they would have to be exposed in the accessibility tree. There's no way that can work with the current design; if they were just .visually-hidden that would be a problem for sighted keyboard users and speech control users, because they would be operable but not perceivable. Remember: the screen reader's job is to convey what is on the screen.

aria-expanded added to it to inform the screen reader user of its state.

It actually does more than that. The presence of aria-expanded informs the user that something is expand-able, as well as conveying the current state. It should make it clearer that the "shortcuts" button reveals some content. You're correct that aria-controls support isn't widespread; I think JAWS is the only assistive tech that does anything with it. However it is the correct recommended pattern for disclosure elements, and works fine in JAWS.

It actually does more than that. The presence of aria-expanded informs the user that something is expand-able, as well as conveying the current state.

Yes, I've got that ;-)

...There's no way that can work with the current design; if they were just .visually-hidden that would be a problem for sighted keyboard users and speech control users, because they would be operable but not perceivable. Remember: the screen reader's job is to convey what is on the screen.

I've always understood that all links on a page should also appear to a screen reader including in the rotor because they are "relied upon" in the operation of the page, so I'm a bit confused by this.

-Kat

A link (or any other content) which is inside a collapsed/hidden container is not "on the page". It can't be seen, nor operated by touch, mouse, keyboard, or speech control; you have to open the container first. Screen readers are no different in this regard: hidden content is hidden.

@andrewmacpherson: I see what you're saying. That makes sense.

During my testing with VO, the menu was expanded on the screen and the rotor still wasn't detecting the submenu items in the list at all. According to the OP in JAWS it shows them in the same line as the Shortcuts link but doesn't read them out. That's what I meant to convey. I apologize for the miscommunication. Hope it helps.

-Kat

This issue summaries; (this one, and the related one) are a bit hard to follow, and conflate several problems.

I'm going through the toolbar with as many browsers and screen readers as I can (including outdated versions I keep around). The behaviours are markedly different; I'm not experiencing any problems at all with NVDA, for instance.. I'll write a summary when I'm done.

Right now, the most significant problem is the mis-use of aria-owns, which sets up a parent/child relationship. Buttons cannot have interactive children, so I think this may be why the links are not available.

You don't say which browser you were using. That an important detail to include, because VO can only deal with what it's been given by the browser.

Sorry, I tested with VO in the latest version of Chrome. If you need me to help out with any testing please let me know. I'm here to help.

-Kat

So since Navigation has been added to the standard profile and recipes:

https://www.drupal.org/project/drupal/issues/3575171

Can we close this issue for D12?