Fixes and visual updates for help and info icons + install KDS 5.2.2

[MisRob]

Summary

• Fixes click on the help “?” icon button not opening the help dialog in
  • Request more space form
  • Edit resource details
• Using KIconButton as is would cause visual regressions because it doesn’t yet account for smaller form icon use-cases. There was no clarity yet in what behaviors we want to make part of KDS, so for now we decided to start exploring better experience with Studio-specific icon button. The icon is 16px and contains further improvements such larger touch target area, and hover transition.
• Because on some pages, visually similar info “i” icon tooltip was used right next to the refactored “?” icon, the “i” icon was updated to match “?” icon to achieve consistent experience.
• Contains related positioning style changes
• Also configures tooltips to have reasonable width, especially on smaller modals
• Installs latest KDS v5.2.2 that has KIcon change needed for this PR

Touch target area agreed with @radinamatic, and visual experience with @tomiwaoLE.

Screenshots

This is how all updated "i" and "?" icons in the screenshots below behave:

icons-recording.webm

Affected places

	Before	After
Request more space form
Edit resource details
Publish channel modal
Quick edit source modal
Public library side panel
Channel details

Reviewer guidance

Usual manual preview of few places mention above, and code review should do. You need to run pnpm install before running the development server.

[MisRob]

@tomiwaoLE I think this should be aligned with your design and thoughts, but in the course of work, I've discovered few more places that will be affected by changes to info "i" tooltip. Before I open this for code review, would you please check all the screenshots above and confirmed it'd be good to go?

[tomiwaoLE]

This all works @MisRob. Thanks for the hard work of capturing all these use cases

[MisRob]

The only change I did in the force push was removal of temporary KDS fork installation in favor of installing now released 5.2.2 that has KIcon change which is needed for this PR.

[bjester]

The previous implementation was keyboard navigable. Although, that may not have been entirely appropriate and correct with regards to accessibility.

It seems to me the help tooltips shouldn't be keyboard navigable, but they should have association with the field. The documentation on aria-describedby seems to fit well with this:

For example, a form control can have a description that is hidden by default and revealed on request using a disclosure widget like a "more information" icon. The sighted users click on the icon to view the description, while assistive technology users can immediately access it as the description is referenced from that form control with aria-describedby

While the previous implementation wasn't correct, adding aria-describedby seems like the appropriate replacement behavior now that keyboard navigation is gone, to maintain some semblance of accessibility :)

[MisRob]

Thanks @bjester.

The previous implementation was keyboard navigable

? wasn't and here it should be fixed. i weren't and still aren't (related to below). Am I missing something - would you point me to a particular place? I've just double-checked unstable and haven't yet understood.

It seems to me the help tooltips shouldn't be keyboard navigable, but they should have association with the field. The documentation on aria-describedby seems to fit well with this

Definitely, I saw that pattern and aria-describedby makes sense, even though for that to work, those icons with tooltips (that are not buttons) need to be able to receive focus in the first place, otherwise screen reader won't really announce anything. I have this update for KIcon in progress as part of my larger refactor of KTooltip to be lazy and better accessible. Additionally, we may need to use aria-label instead of aria-describedby, because aria-describedby is said to not function properly when referenced element is not in DOM (which will be the case because of lazy loading). As soon as I have a preview ready, I would like to fine-tune everything with Radina.

I wouldn't mind improving some parts in this PR if you can think of anything - just not aware how to achieve better a11y without the prerequisites mentioned above.

[bjester]

To clarify, my thoughts were mostly towards the tooltip as help and information text, to adjacent things. I think those situations may have a distinct purpose that differentiates itself from a general purpose tooltip, which is more likely tied to the same thing. Also, within the context of a form where a help/info tooltip for a field would exist, I don't think there's a need for lazy loading, because we wouldn't expect to have potentially unlimited instances of it at a time, meaning aria-describedby is an option.

I noted that before the changes, it seemed that the help tooltip's DOM element could be "activated" by keyboard. While this may not be entirely useful, it seemed that best remediation for it would be aria-describedby.

those icons with tooltips (that are not buttons) need to be able to receive focus in the first place

It wouldn't be the icons/buttons that should have it, but the form field. The help tooltip isn't describing the icon/button, but the field's purpose

[MisRob]

Ah okay @bjester, I think I get better how you meant it, thank you.

There's more things. I think the first two points are relevant particularly to this PR. (3) and (4) is continuing discussion for future tooltips - if you had any further thoughts on that too, let me know. I'd be also happy to have you join PoC review as soon as I have it ready.

• (1) It sounds that the main point is linking a tooltip text with the relevant element, typically form field. Good idea, yes. Just applied aria-describedby to those use-cases where it seemed meaningful.

• (2) Yes, keyboard navigation into the tooltip element itself is not useful, APG pattern actually discourages it: "Tooltip widgets do not receive focus". In any case, I think we can keep it as a separate point from (1). aria-describedby should still be helpful - I've just learned that it's not even limited to focusable fields, and can be used fairly generally to establish relationship of an element with an additional description.

• (3) I appreciated your note on form field focus, rather than tooltip icon focus itself. As soon as we have keyboard functioning properly, then yes - when a form field is in focus, I too think it'd be best to have ring around the formfield and have tooltip displayed on the very same TAB press. Will fine-tune with Radina, but already pretty sure that this would be better experience than having to press TAB twice. It'd be also nice if KDS form components would have all this baked in for most common uses-cases, e.g. we'd just provide tooltip text to KCheckbox or KTextbox, and it would take care of icon, positioning and a11y.

• (4) As for lazy loading, it'd be probably best to have it as optional then. And then have guidance in KDS documentation explaining that turning on lazy loading requires a bit of additional work in a consumer for full a11y - most commonly via aria-description, but that would depend on context.

[bjester]

I think this is a huge improvement, on many levels! Thanks for working with me @MisRob, to better Studio's accessibility