Overview
When you add a title to a navigation block (using the Navigation.module module) in the admin menu, it is not focusable when tabbing through, whether or not the menu is extended or collapsed. This means that users with a screen reader do not get the information contained within that title, which is formatted as an H2 and provides information about the subitems underneath it.
Steps to Reproduce
- Login to Drupal, and enable Navigation
- Observe that all the navigation block elements are
<h2>elements, which is the same level as headings in the rest of the page.
Previous Summary: Problem/Motivation
A follow up to #3435989: Add Collapsed Status for Menu Block Title, I've noticed that the titles for navigation blocks cant receive focus when stepping (tabbing) through the navigation. since it is not focusable that structuring / wrapping element is unavailable for a user tabbing through the menu and is going announced/unnoticed to screenreaders in this context. the only cue and information are five headings (just looking at the activated titles for the default navigation blocks). the announcement in voiceover looks like this:
- h3: Administrative toolbar content
- h2: SHORTCUTS
- heading level 4
- h2: CONTENT
- heading level 4
- h2: ADMINiSTRATION
- heading level 4
- h3: Administrative toolbar footer
- h4: RKOLLER
just based on the announcement it is not clear what shortcuts, content, administration, rkoller actually are, or better that shortcuts and the rest of the h2/h4 are actual navigation blocks. with the screenreader you are missing the visual context available to sighted users. about h4: RKOLLER, i would assume it is about my username but there is actually the top level menu item about help wrapped inside as well, therefore the username is inaccurate as a label for the two. In addition to that if the same pattern was followed as for the navigation blocks for the administrative toolbar content region rkoller would have to have h2 instead of h4.
it also has to be noted that there are three empty visually hidden h4 elements. and in general there is no consecutive way getting an announcement of the different parts of the navigation in consecutive order due to the fact that you have headings, and the top level menu items either being buttons (with submenu) or links (without submenu), you have to let voiceover start reading the entire page in consecutive order with (VO-A) to get all parts in context.
Proposed resolution
Discussed with @mgifford, @rkoller, and @kat-shaw about this on a Zoom call.
- There should be a parent
<h2>element that communicates that this is the administrative sidebar - The
<nav>landmark element should use this heading as its accessible name - All nested headings should be
<h3>'s to allow a hierarchy.
Issue fork drupal-3439643
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- main
compare
- 3439643-block-title-accessibility
changes, plain diff MR !7973
Comments
Comment #2
rkollerComment #3
katannshaw commentedI'm also seeing three instances of these focusable yet visually-hidden headings.
Because these are meant to be visually-hidden headings, I'd recommend the following proposed solution:
1. Add missing heading text for each of them
2. Remove the CSS class
.focusableComment #4
ckrinaComment #5
ckrinaThanks @katannshaw! Updating the issue summary with the detailed recommended approach to make it easier to understand and address the issue.
Comment #6
sjhunsinger commentedHey there, I'm working on this issue at the Mentored Contribution during DrupalCon Portland 2024. I'll be working on this for the next few hours.
Comment #7
scottatdrake commentedWorking on this issue during the mentored contribution DrupalCon Portland 2024.
Comment #8
deivalko commentedHello. I'm working on this at the DrupalCon Mentor Contribution in Portland 2024.
I will be working on this for the next few hours.
Comment #9
hktang commentedHi, I am working on this at the mentor contribution session in Drupalcon in Portland 2024. I will be working on this for the next few hours.
Comment #10
joshmillerHello! I'm working at the mentored contribution in Drupalcon Portland 2024. I will be working on this for the next few hours.
Comment #14
mrcgomez commentedHello! I'm working at the mentored contribution in Drupalcon Portland 2024. I will be working on this for the next few hours.
Comment #15
emoleee commentedHello! I'm working at the mentored contribution in Drupalcon Portland 2024 too. I will be working on this for the next few hours.
Comment #17
sjhunsinger commentedSo far we have accomplished the following:
Up next:
We'll be back at it after lunch!
Comment #18
emoleee commentedI am working on this issue at DrupalCon 2024 PDX and will be working with it for the next few hours as well.
Comment #19
sjhunsinger commentedComment #20
sjhunsinger commentedComment #21
sjhunsinger commentedComment #22
hktang commentedWe've got some feedback and further information from @rkoller. We are summarizing these and provide an update soon.
Comment #23
thehuffman commentedI am also taking a look at this issue as part of contribution day at DrupalCon Portland 2024.
So far I'm not seeing the
titlevariable (see line 4) ever get populated in thenavigation--menu.html.twigtemplate. Either way, I'm also seeing a heading level is being skipped between the menu template and its parentblock--navigation.html.twigtemplate.We might consider not outputting a heading in the menu template, and instead provide an
aria-labelattribute for the<ul>, which would use thetitlevar as its value.Update:
Assuming I'm looking the right place, I don't think the title var is ever output in the template: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig...
Comment #24
scottatdrake commentedWe are out of time today. We spoke with the original opener of this issue, rkoller, via slack. The thread can be found at: https://drupal.slack.com/archives/C7AB68LJV/p1715202081200079
rkoller is using voiceover on a mac, and looking at the headings using voice over's rotor feature. The uploaded video nicely illustrates this.
Comment #25
deivalko commentedSome hopefully useful context:
https://www.w3.org/WAI/tutorials/menus/structure/#label-menus
This is an indication that the invisible h4 tag is desirable, but in the time I've had, I haven't found an explanation for specifically why this is useful or what the outcome should be. That section includes a link to https://www.w3.org/WAI/tutorials/page-structure/labels/ which might be more useful.
Comment #26
jacobupal commentedComment #27
jacobupal commentedRemoving novice tag as the next steps require some specialist expertise.
Comment #28
kentr commentedThe markup might have been changed in #3452724: Navigation side bar and top bar should have appropriate aria labels. From what I can tell:
With the default configuration, I see
h2in the voiceover rotor headings menu:So, the IS might need updating.
I can't verify currently b/c I'm experiencing a problem with configuring the block (maybe a bug, and definitely a separate issue): CSS seems to be broken, there's no pencil icon, "Configure" and other options are displayed and very unstyled, and it's not possible to click "Configure".
Here are some notes on the STR from my experience. I'm also not editing the STR b/c someone who is more familiar with it should verify:
/admin/config/user-interface/navigation-block, you need to click the "Enable edit mode" button before you see an option to configure anything.Comment #29
kentr commentedIt turns out I can click "Configure"...
With titles displayed, there is no
h4. It's still just theh2block titles. This is consistent with #3452724: Navigation side bar and top bar should have appropriate aria labels. For this, I do think it needs an IS update.However, I still can't reach them with the
tabkey.Since it's possible to tab through the menu items, it doesn't seem necessary to also tab to the headings.
Here's a screenshot of the rotor menu when the block titles are displayed.
Comment #31
mherchelDiscussed with @mgifford, @rkoller, and @kat-shaw about this.
The success criteria is to
Comment #32
mgiffordIn the meeting we decided that this was a stable blocker.
Comment #33
mherchelOK! This should be good to go!
Comment #34
mherchelUpdating IS
Comment #35
rkollerlooks good thank you! i've tested with voiceover's rotor as well a with this little bookmarklet: https://a11y-tools.com/bookmarklets/#navigateLikeSR
the only detail to note is that the workspaces menu item is missing a heading. but that is probably a shortcoming on the end of the workspaces module and the menu item needs some refinement? and for reference the administrative sidebar name is discussed in #3539715: Review navigation landmark naming. cuz from my point of view "administrative sidebar" not necessarily communicates that this is the main administrative navigation. but that is out of the scope for this issue, sticking to the status quo in regard to terminology is the right call for this issue.
Comment #36
kentr commentedI haven't looked at the code.
If this problem is likely to occur with other modules adding to the Navigation, then it's worth looking at this from the Navigation module: Something like automatically adding headers for sections that are injected from other modules.
In the end, I'd think that it's the Navigation module's responsibility to ensure that everything it renders is structured correctly.
Comment #37
mherchelThis is a potential followup issue. Way out of scope for this.
Comment #38
bernardm28 commentedLooks good, I wish we could do something with random like clean_id or something. Other than that, it seems to achieve all the goals.
Comment #39
mherchelThanks for the review. Yeah, the random() is needed, as the clean_unique_id filter can be problematic in cache
Comment #42
longwaveHad the same thought about random vs clean_unique_id but it was answered above. There's already the use of clean_unique_id in this template but then the variables it sets appear to be unused, but that's out of scope to fix here.
Backported to 11.3.x as an eligible accessibility fix. While this does change the markup slightly it's only admin markup and to me the fix outweighs any possible disruption.
Committed and pushed adb94030dfb to main and 9b05c0ff34d to 11.x and dcdd4cfcf53 to 11.3.x. Thanks!