I'm still investigating why the sticky header isnt showing. For the first link in the description (https://eu.wikipedia.org/wiki/Txikipedia:Munduko_zazpi_mirariak) I believe its because the sticky header isnt available in that namespace 104. For the second, (https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Lehiaketak/2022/04) I havent found any obvious reason why its not working. I probably have to setup page banners locally to reproduce and debug.

Those results look expected. The issue with the menu placement is tracked here: T311178, although it will likely be fixed by T311447

Related task: https://phabricator.wikimedia.org/T310828

Since the collapsed TOC uses the checkbox hack, this can be accomplished by using JS to progressively enhancing the collapsed TOC. Most of the other checkbox hacks in Vector contain links, so this issue hasn't come up before.

In T310388#8023828, @Jdlrobson wrote:

Banners are also JavaScript so we could do a banner height calculation to change the top calculation on the menu when a banner is present.

I realized I missed another option, which is to simply move the site notice out of the main element and above the TOC. This would mean the site notice is no longer part of the main landmark, but this might not be such a bad thing as the content isnt related to the page. Doing so would also mean the site notice spans the entire width of the page, and there may be implications on how easily accessible the notice is because it's no longer after the skip link and the main landmark. I'm not sure how important that is, but if fundraising banners go there that might be tricky.

Fixed by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/807603

@Jdlrobson
I realized that the second case in the description (i.e. collapsed TOC in the sticky header) isn't possible until T307901 is complete. On viewports greater than 1000px the TOC is sticky on the side by default, we need the hide button in order to trigger the TOC to appear in the sticky header. The work involved in getting the TOC in the sticky header is pretty distinct from the first case anyway, so I'd recommend splitting that into a separate ticket.

In T307900#8002882, @alexhollender_WMF wrote:

2. the way i'm thinking about it is: if we're presenting the TOC in a menu/panel (which currently only happens below 1000px, but eventually will be possible even at larger screens), it should act as other menus do in the sense that if you open it up, then click on an item, the menu automatically closes. does that make sense? i don't think it's a high priority, so if it's complex we can definitely create a separate ticket and worry about it down the road.

Yes that sounds like a good idea!

I put up a POC fix with an approach that basically does T308055, and separates the site notice from the rest of the page content. Another solution could be to rework the approach for the collapsed TOC altogether, and duplicate the TOC in the DOM (i.e. https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/794029).

@alexhollender_WMF The code originally has the sticky header search bar set to a max width of 500px. Do you want me to change that to 520px?

This task will require JS to add/remove classes when the "hide" and "move to sidebar" buttons are pressed.
EDIT:
This task can be accomplished by leveraging the approach taken in T307900, and simply updating the CSS to work with the new classes in addition to the media querys. This would still have the same a11y issues as the original approach.

After doing some more research, I believe that this task isn't as straightforward as just adding some attributes. Due to the design of our tabs, there are 2 tabs that are active on a given page (i.e. "Discussion" and "Edit"). aria-current can only be used once per page, and aria-selected can only be used in the context of a [[ https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-manual.html | tab component ]], which also only has the concept of a single tab selection.

@cjming I just chatted with @Jdlrobson, and it sounds like we should go with the simplest solution for now in the interest of unblocking the TOC, i.e. going with your original approach of styling the original TOC element, and also adding an a button element before the h1. Jon also mentioned concerns about the duplicated ids, and that there might be a point later on where we can think of a better solution, i.e. using JS to move elements to the right location when needed.