Given the low effort of implementing the positive tabindex approach (changing a few lines in the Mustache templates), I recommend we move forward with that approach because although it's considered an anti-pattern, it effectively solves this issue for mobile as well as non-JS users. If it becomes a maintenance concern in the future, then we can re-evaluate a JS based focus-looping technique.

I've been exploring the feasibility of solving this via the DOM order change, i.e. moving the sidebar back inside the header element.

Besides the two approaches considered above, which can be summarized as:

Just to recap the work done in this task: In accordance with the arguments presented above, the DOM order in modern Vector has been changed to reflect the visual flow of the page.
These changes will let us: shed a significant portion of the legacy CSS, improve the presentation on smaller screens, improve the loading experience, and bring Vector in line with more common accessibility patterns on the web.

Looking at the link @Volker_E mentioned, https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#File_organization

I'm moving this back to the backlog. because as discussed in the gerrit patch here I think we should create a separate variables file for modern Vector if we're going to have different font-related variables (at least at first) in modern and legacy Vector.

Regarding the entry files: skin.less and skin-legacy.less, I was thinking about naming both skin.less since they'd be in different folders. This is similar to the convention in Node of using index.js in multiple places. The downside of that however is that searching for those files in an IDE is difficult because they both have the same names (maybe not a big deal though). Another approach we could use for these entry files is to name them after their ResourceLoader module, so
skin.less → skins.vector.styles.less
skin-legacy.less → skins.vector.styles.legacy.less
That might be overthinking it though...

@Volker_E I like skins.vector.styles.common/ for consistency. I've updated the description with that, also including where layout folders could go.

In T213778#6506545, @Quiddity wrote:

+1. As a reader & as an editor, I also appreciate the subtle hint that a link is going offwiki but within Wikimedia, e.g. from Wikipedia to Wiktionary, such as in the link to "toponym" in the (featured-class) article https://en.wikipedia.org/wiki/Nahuatl#Vocabulary

I definitely agree with removing the term "body" from these classes. That's certainly confusing.

@Bouzinac Although this is certainly a bug, given that switching to "advanced" mode is a workable solution, this isn't likely to be given high priority.

I love the chart on https://www.mediawiki.org/wiki/Design/Link_colors, can we mirror that in the description?
I think what we want from this task is:

The technique of modifying focused elements with JS is typically called focus trapping (or looping). There's a good writeup on medium of the general implementation here: Focus Trapping for Accessibility (A11Y) . It generally involves checking which element is focused and changing the next focused element during a keydown event.

We refrained from estimating this today for the following reasons:

1. We weren't sure where these link colors are defined, and if this change will require a change in core,
2. If it's just in Vector, we weren't sure how to separate the color variables for legacy and modern vector
3. We weren't sure how to change the colors of the related "external link" icon (or any similar icon that appears as part of a link).
4. We think this change requires some community consultations.

@Iniquity thanks for mentioning the CC attribution. The individual files we're uploading are actually split into workmarks/tagline e.g. frwiki-wordmark frwiki-tagline. I was thinking these files, since they are just text in an open-source font, might actually be public domain as they might not meet the Threshold of originality to have any license at all.

I've been thinking of doing this for a while now, here are my thoughts.

was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list).

Is this mainly a question of vocabulary? I think the usage itself is consistent with the BEM concept of modifiers.

The implementation can live within WVUI if potentially useful to any search consumer or directly within Vector if not.

I assumed since this loader should kick in before the Vue library loads, that it should live in Vector.

Are we receiving feedback that this behavior is problematic? If we know this is the eventual final state, I wonder if we need to do anything here?

in terms of testing before the javascript has loaded, the Chrome devtools provide a neat network throttling capability

I did a bit of research as to why this happens. I wasn't aware of this browser behaviour, but apparently, when you click on an internal link <a href="#target">menu link</a> the target element <h2 id="target">over here</h2> actually gets the keyup event if it's focusable. Since our menu button uses tabindex=0 to force focus, it receives the keyup event that originates from pressing the "skip to navigation" skip link.

I found a bug with this implementation. When clicking the "jump to navigation" skip link, the sidebar changes state. The patch above provides a fix by removing the keyup event binding on the checkbox hack. I'm not 100% sure why that event binding causes this to happen, but removing it prevents this behaviour.

... and promise that results will be presented as quickly as possible.

Also re:Loading indicator, I think we have to take into account when we exactly we want that to appear, and how likely it is that someone will see it.
I don't know if we've settled on the loading strategy for the widget, but if we load the code for the widget lazily, e.g. we wait until someone focuses or hovers on the search input before we initiate the search-suggestion code, then it's likely that the initial search suggestions will be delayed (for the benefit of loading less code upfront). In this scenario it might be good to notify the users that some results are on the way, but if we show some sort of loading indicator on subsequent API requests, while users are typing, in between keypresses, I think that might be distracting.

Re: Namespace search. The search API only searches the main namespace unless the beginning of the query matches the namespace name exactly.