One concern is that this would essentially make the menu button do nothing to a screenreader users perspective, which could be unexpected.

@bwang I think this concern is spot on! We want to try to match the experience of screenreader users to non-screenreader users as close as possible. This would mean forcing assistive technology to be very explicit that the hamburger is a toggle button that expands and collapses the table of contents.

I think a good WCAG guideline to follow is: SCR28: Using an expandable and collapsible menu to bypass block of content

Here is the working example that WCAG presents (I would just substitute the innertext of 'Toggle navigation bar' here with 'Toggle table of contents').

Edit: Here is the exact guideline for this specific situation from WCAG: https://www.w3.org/WAI/WCAG20/Techniques/working-examples/SCR28/toggle-toc.html#sec1

Right now, VoiceOver just tells me that the TOC hamburger is a menu, which is not great. It definitely needs to be more verbose.

I would add, at the minimum, innertext to the hamburger that says "Toggle table of contents" and just style it with the u-visually-hidden mixin you mentioned.

@KSarabia-WMF Sorry to clarify, we already have a task for fixing the missing label on the collapsed ToC toggle (T328584). Once that task is completed, the toggle should be working as expected as a menu popup toggle button.

We want to try to match the experience of screenreader users to non-screenreader users as close as possible.

The idea I'm exploring in this task is actually the opposite of this. Rather than match the experience for screenreader users and non-screenreader users by hiding the content based on the dropdown toggle button, should we allow the content to be accessible to screenreader users all the time? The idea behind this that perhaps even a correctly implemented collapsible menu introduces barriers for screenreader users who expect to be able to directly find and navigate to the contents of the ToC, without needing to use additional toggle controls.

@bwang Ah, got it! I think my main concern is that this solution would create a significantly separate user experience between two distinct groups. My instinct is that we want to provide "equivalent experience." Screenreader users should get to have that same same sensory feedback that non-screenreader users get when they toggle using a mouse.

However, I get that the hamburger is unwieldy especially on iOS VoiceOver and Android Talkback. If we decide we want to expand the TOC at all times for screenreader users, it begs the bigger question of why we also shouldn't expand it for non-screenreader users. Who are we to say that some sighted folks aren't also having trouble finding the TOC when it is collapsed? Just some food for thought!

@KSarabia-WMF Yeah that makes sense. That was our original assumption when implementing the dropdown menus, that they should behave the same.

I do think there are some key differences between screenreader users and sighted users in this case. We move links into dropdown menus to reduces visual clutter, but this doesn't really apply to screenreader users, who already have the ability to skip through page tools, the toc, or main menu contents. Meaning the ability to pin/unpin menus isn't really relevant for screen reader users. In the case of the TOC, which pins on small viewports automatically, screenreader users wouldn't have any indication that the TOC has moved and is now inside a dropdown. Even if the dropdown is correctly implemented, this could introduce discoverability issues.

If we decide we want to expand the TOC at all times for screenreader users, it begs the bigger question of why we also shouldn't expand it for non-screenreader users. Who are we to say that some sighted folks aren't also having trouble finding the TOC when it is collapsed?

Sighted users definitely are having trouble finding it when it auto collapses, but thats why we have T311160. In this case, it doesn't make sense to handle screenreader users and sighted the same. We cant expand the TOC at all times for non-screenreader users because that defeats the point of pinning. And we having the notice in T311160 also announce the new location for screenreader users is meaningless. While in general we do want the experiences between sighted and screenreaders to match, i think it also depends on context. Another example of this is the sticky header, which is actually entirely hidden from screenreader users because it contains duplicated content.

Overall I'm not set on this approach, but I still feel like there's something we can do outside of just making the dropdown work as expected for screenreader users.

Another option could be to move the h2 from outside of the TOC element to right before it. The h2 would be visually hidden. This would work well, but would be slightly more verbose as there will be multiple labels saying "Content".

Another option could be to move the h2 from outside of the TOC element to right before it. The h2 would be visually hidden. This would work well, but would be slightly more verbose as there will be multiple labels saying "Content".

Thinking about this more, I think this is a good compromise between providing more affordances to screenreader users to access the TOC, while still maintaining expected screenreader behavior for dropdown menus. This is captured in T330324, and I will be closing this ticket.