@pmiazga The path we've taken now is to provide native selects when the isMobile flag is set true (MinervaNeue sets it and it could be unset dynamically at a certain media query to enable custom dropdown on desktop again).
You need to use a OOUI DropdownInputWidget to benefit from this solution. The advantage is, that the native handling by the OS/browser is known to users and should be optimized for the specific platform and that you're still able to interact with the dropdown dynamically per JS in the OOUI way.
Normal DropdownWidget's are not providing the select (in OOUI terms input).

Accessibility testing tools: The personal favorite and currently most reliable is [[ T223309 | deque aXe ]].

Agreeing with @tstarling here. Screen reader navigation through semantic headings seems acceptable for AT users.

Keeping it open until we've got a clear task to merge this into…
Also removing Accessibility tag, tables can be made accessible when they contain a caption element, marking up header rows as th and include optionally thead, tfoot.

With T117781: Convert Special:Preferences to OOUI resolved the checkbox labels are bound to the checkboxes via id and for. The labels above are still marked-up as labels, but shouldn't be an issue in modern browsers/AT combinations any more.

This needs to be declined in context of Advanced Mobile Contributions. We've been discussing a better content representation there and will apply a responsive solution.

Most recent major collapsible refactor took place in T42812.

In T223155#5181865, @Krinkle wrote:

In the above screenshot, I feel disoriented as a user. The surrounding page frame, the toolbar, the sub toolbar, and the editable text area are all flat white with a black foreground. There is no hierarchy or balance to orient the user (e.g. color or shading). Even in flat designs, this is usually addressed in some way with colours. Are there plans to address that?

Also sharing on task, the arrows should be replaced in WikimediaUI style by carets

In Vector this is also a usability improvement with expanding the tool click area from 26x26px to 32x32px.

As we probably can't easily add ids to the collapsible-content and a connected aria-controls attribute (which has been stated to be dysfunctional in several readers at 2016), we should nonetheless add aria-expanded attribute to provide direct feedback on the button about its state apart from showing and hiding text content in DOM afterwards.
In this way, we provide a second, label-independent, standard feedback to screen readers.

@iamjessklein I'd be interested to hear how the current take on the spinner came together. Although it might have been used in Foundation products, it has never been a standard widget as stated in T75972.
I really like the progress made on the ticket, but share @matmarex' take on the spinner being less noticeable and think an indeterminate progressbar underneath the toolbar could be a viable alternative.

Stalled until next package update attempt.

@kaldari ^ Functionality re-enabled in short-term solution for Hackathon!

@Jseddon Small comment, without having access to Nirzar's original designs. The background on the close icon seems to me to give that element too much visual focus. The message should be in the focus and then a clearly indicated way to abort the message.

@Jdlrobson Just filed a follow-up subtask.

I think, @Amorymeltzer's concern is not completely wrong. The button says 'show' it has no clear indication for a screen reader what it will show, sure the next thing in the DOM is the form's legend, nonetheless a clearer connection (maybe an aria-expanded attribute on the collapsible element as first idea).
Nonetheless I think this specific task is resolved and the questions raised belong on more general tasks.

Pls ignore above comment, I was on a page that didn't receive scrollbar and therefore moved around with scrollbar appearing. That's additionally to the already existing slight movement of the search overlay on focus.

@Jdlrobson I couldn't reproduce the button background and border issues. With the all the additional patches above, there's only one thing remaining from my POV:
When focussing the overlay the search box moves further than before. On a first skim, I couldn't pin-point what rule causes this.

As mentioned on the main task, the original idea of moving the styles to a 'forms.less' was not completely wrong.
There are inputs, buttons, maybe textareas and selects outside of special pages, which need to receive styling.

When a language is chosen (in the examples for problem #1 of the task description Hebrew), it becomes the primary language and everything layout is right to left until a part is LTR. I've tried to capture this in T222867.
Except where it doesn't make sense layout-wise and would lead to more noise and confusion (the dropdown position in Hebrew for the caption language). Do you agree with such generalization, @Amire80 @Ladsgroup @Mooeypoo
Specific unclear cases should be user-tested.

@Ramsey-WMF Without having tested myself, Farsi fa should be in the list I think.

@JTannerWMF I've identified an issue in my last test of the patch, shared at T209911#4999438

code, kbd, pre, samp seem sufficient for all other skins. Putting this on resolved, as Timeless decided to go with tt.

@MGChecker Because there are viable alternatives already defined: code or kbd. Why leaving it in and making things more complex long-term?
MediaWiki is not an entity on its own, it's part of the Open Web. And the web evolves. With and around browsers and standards. When people come to MW they have to learn a deprecated tag which is nowhere used. That's an unnecessary hurdle.

The problem it solves is uneven distance when vertically centering something at the default font-size. It's a visual glitch.

@Jdlrobson So the scope of the task was originally defined by the tasks written then.
Nonetheless I would like to extend it by moving the remaining bits out of reset.less and getting rid of it completely.
That's my personal success criterium for this task.

@kaldari Had the same thought. I can't care about the mid-term preferable solution brought up by @matmarex to build the demos on top of Webpack in time for the Hackathon. Not sure about @Jdforrester-WMF attempt above.