0

I'm working on an accessible input component with built in tooltip. I've managed to create a solution that seems to work fine for people with limitations — whenever user focuses that input with keyboard, not mouse, if he doesn't start typing within half a second a tooltip appears and screen reader reads it.

However there came some cases with links inside tooltip, meaning user must be able to navigate inside a tooltip cloud and focus links.

What could be the pattern to use here that would be intuitive to the user? Using tab to navigate inside the cloud might not be ideal since one might expect it to move to the next control on the form. Using arrows to navigate focusable elements in the cloud seems not that intuitive and it gets in the way of autofill.

I was hoping maybe somebody here has experience implementing such a case and could share his insights. I know one way would be to keep hints clear of links and show such info explicitly on the page, but that's outside my control.

0

Change the link to plain text and use scripting to implement, for example if the action is to link to a page that has further help, the script could say:

An input box is used to enter text on the screen, for more help press

Where the script will pick up the key press combination and implement the link, rather than the user having to jump to the link or the URL being read.

0

Having links inside tooltips is bad news and can cause a lot of trouble, depending on the devices / assistive tools used.

We decided to use a "Popover" for this, not a tooltip, meaning that it will be toggled on/off by Enter, not just by being focused or hovered. That makes it much easier for the user to move into the open Popover and interact with it. I recognise that it might not work well asking users to press Enter inside form fields to toggle Popovers, so I think you'll find it difficult without modifying the design of the application. Adding a help icon after the input might be an idea, or simply adding the help-text visibly underneath the input.

0

There are two changes to be made if you are working on an accessible tooltip solution.

Avoid automatic presentation of a tooltip when user focuses a UI control with keyboard. There are warnings about it in WCAG. There must be a clear action that would invoke a tooltip. Also, there must be a separate action that closes it, such as close button inside. Navigating to the close button with tab is a perfectly fine solution since you have changed the content and layout of controls on your screen when popped up that tooltip.

Avoid using any hyperlinks or other actionable elements apart from the close button inside the tooltip. A tooltip should provide brief explanation to a UI control of peace of content in plain text. If you need links or buttons inside this is not a tooltip any more. Rethink how information is laid out and use more appropriate mechanisms such as dialogues, expansion panels and such.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.