Change 406307 had a related patch set uploaded (by JaydenKieran; owner: JaydenKieran):
[oojs/ui@master] Set help button tabIndex to -1

https://gerrit.wikimedia.org/r/406307

@JaydenKieran Putting tabindex: -1 makes them completely inaccessible for keyboard users.

@Volker_E Can we set the button to an access key instead to retain that accessibility? It just doesn't make a whole lot of sense to cycle to the help elements on tab, especially when you're trying to quickly fill in a form. Alternatively, another solution where we can keep this functionality but move it away from tab, as I know access key can behave differently per browser.

@JaydenKieran Before stepping into changing this on a general level for the whole library used in various interfaces and possibly overthrowing already learnt behavioural patterns by users of these interfaces, I'd like to take a step back and would like to know which place you came across where the current way was standing out to you?

@Volker_E Well, anywhere that the help buttons are used in conjunction with a form, whether that be a custom gadget/script that utilises OOUI or an extension. Whenever I've used forms elsewhere (outside of MW), tab has cycled through each input on the page, not any guidance or help text. It's a slight annoyance from my perspective that there are extra key presses required to cycle to each input, especially when there is a form with a lot of inputs and each have their own help buttons.

Perhaps a better idea, rather than completely blocking out keyboard accessibility - which admittedly I wasn't really thinking about when submitting a patch, so feel free to effectively disregard it - is to rethink how the help element is interacted with on each input. Some libraries hover the text to the side of the input when it is focused, is that something that might be better for this?

Change 406307 abandoned by JaydenKieran:
Set help button tabIndex to -1

https://gerrit.wikimedia.org/r/406307

In T185752#3925054, @JaydenKieran wrote:

Perhaps a better idea, rather than completely blocking out keyboard accessibility - which admittedly I wasn't really thinking about when submitting a patch, so feel free to effectively disregard it - is to rethink how the help element is interacted with on each input. Some libraries hover the text to the side of the input when it is focused, is that something that might be better for this?

Yeah, I would look at the issue from this perspective. I think literally nobody likes our current "help" buttons. They are inconvenient when you want to view the help text (they require clicking a small target that is often way off to the side), and they are inconvenient when you don't (they get focussed when tabbing, as you say).

Two recent examples where people have been complaining about them:

• T181854: Better handling of 'instruction text' on Preferences tabs for Recent Changes and Watchlist
• https://commons.wikimedia.org/wiki/Commons:Structured_data/Get_involved/Feedback_requests/Multilingual_Captions#Version_2:_Caption_field_added;_help_text_visible (quietly changes the design from the help buttons to always visible help text)

I guess we might want a different task to talk about this.

Another OOUI-based interface that doesn't use "info" buttons, and instead has always visible labels, is Special:ApiSanbox:

https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query

Now, it may not be the pinnacle of good design, but I think this is another proof that we should have something like this by default.

On T130496: API sandbox's descriptions are positioned and styled poorly there is actually a proposed redesign for those labels, keeping the general idea but making them a bit prettier.

@JaydenKieran From a UX perspective I'm not happy with the current representation and interaction sequence either. And I agree that the tab focussing can get a little bit in the way of fluent keyboard user workflow. What we were trying to do on some views already was double-checking the info tooltip parts and see if we can boil them down and integrate them instead into the form labels where possible.
Your proposal is interesting and we will look into alternatives.

An example where inline labels would result in worse experience for many users (Special:Preferences Beta):

An idea for a first step towards a solution could be to have a different help trigger in forms (helpInline?), so designers & devs can choose from PopupButtonWidget or inlined labels – such we don't break existing, complex, verbose layouts and still provide a way out.

A word of caution: Without an alternative way we would break things badly – like in example above. Without additional guidelines and best practices around it (maximum length of text), what to put where best (form element label vs placeholder vs popup help or inline help) we won't add value.

Some experimental patches to see results in the demo:

In T185752#3925054, @JaydenKieran wrote:

Some libraries hover the text to the side of the input when it is focused, is that something that might be better for this?

Auto open popups: https://gerrit.wikimedia.org/r/#/c/433132/

In T185752#4156031, @matmarex wrote:

Another OOUI-based interface that doesn't use "info" buttons, and instead has always visible labels…

Tiny labels for help: https://gerrit.wikimedia.org/r/#/c/433310/

An idea for a first step towards a solution could be to have a different help trigger in forms (helpInline?), so designers & devs can choose from PopupButtonWidget or inlined labels – such we don't break existing, complex, verbose layouts and still provide a way out.

That makes sense.

Without additional guidelines and best practices around it (maximum length of text), what to put where best (form element label vs placeholder vs popup help or inline help) we won't add value.

I agree, we'll need best practices here. Also, these aren't black and white guidelines as I understand them. Some times the help text is very long, but essential for the user to not make a mistake, so must be inline and not be hidden behind an icon, at other times it's small but not important. Where would we keep these guidelines? The style guide? Choosing between icon help and inline help could be part of the intro documentation for FieldLayout, it already talks about help.

I just remembered that we also have notices, and the help config documentation has the following line:

From FieldLayout - help config:

For important messages, you are advised to use notices, as they are always shown.

We might need more clarification here too.

Change 433310 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] FieldLayout: Add helpInline config

https://gerrit.wikimedia.org/r/433310

Latest patch set, with small amendments based on my recent feedback (Base 20 instead of 30 and 13px equivalent font).

Positive aspects from my perspective:

• all issues with current info icons resolved
  • quicker tabbing through form, decreasing form completion time
  • immediate visibility, but still subtle appearance, which shouldn't get into users' way too much
  • discoverability issues gone, especially for mouse-only users
• freedom of choice for product owners between two options for extended labels, depending on their interface needs

Negative:

• choice might lead to more confusion and might weaken learnt behaviour. Imagining that popup help icons will disappear more and more.
• possibility of having both versions side-by-side, which is confusing, although not too problematic. Anyways, we'd need to strongly voice where to prefer which and cleanup existing interfaces
• more crowded interface if not applied carefully. Little influence on translations' length.

Change 433310 merged by jenkins-bot:
[oojs/ui@master] FieldLayout: Add 'helpInline' config

https://gerrit.wikimedia.org/r/433310

This was released in OOUI v0.27.2, which will roll out with MediaWiki 1.32.0-wmf.8.

Change 439908 had a related patch set uploaded (by Esanders; owner: Esanders):
[oojs/ui@master] Follow-up I90a0a787: Add 'helpInline' to FieldLayout.php

https://gerrit.wikimedia.org/r/439908

@Esanders Thanks, I was thinking the same.
I'd like to resolve T196738 as UX and accessibility blocker to this first though, especially before we start to use the new 'helpInline' in production.

I also think the order is not right for align:top, the field should come immediately after the label in read order, that is already the case in align:left as you scan right from the label, but not in align top, where it goes label>help>field.

In this example the large disconnect between label and field makes it really hard to parse:

much better whould be:

That's a though one, I'm not completely convinced about below being clearer. What the new 'helpInline' exposes much clearer as issue: label texts, even secondary should be short and dense.

The help should be additional information the user can read should they be having trouble using the form using just the primary labels. Wedging it middle of the normal read flow forces them to scan it before getting on to the field. It's auxiliary information and should be presented as such.

But the proposed treatment would still break the flow, eyes moving down, then up again, then down.
Exactly what we intended to resolve with this possibility. If there's too much text, one can stick to the help PopupButtonWidget.

But the proposed treatment would still break the flow, eyes moving down, then up again, then down.

The primary use case is that user figures out how to use the form from the label and the field alone. If after reading those they are still stuck, they advance to the help text, then return the finish filling in the field. In the primary case the fill out the field, then scan down to the next field heading.

The first layout would only be better if we assumed the user would mostly likely have to read the help text to fill out the form, but that shouldn't be the case.

Forked discussion to T197004.

Change 439908 merged by jenkins-bot:
[oojs/ui@master] Follow-up I90a0a787: Add 'helpInline' to FieldLayout.php

https://gerrit.wikimedia.org/r/439908