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.

4 Answers 4


There are two changes to be made if you are looking for an accessible tooltip solution.

Avoid automatic presentation of the tooltip when user focuses a UI element with keyboard. There are warnings about it in WCAG. There must be a clear action that invokes a tooltip. Also, there must be a separate action that closes it, such as a close button inside the tooltip. Navigating to this close button with tab is a perfectly fine solution, since the content and the layout of UI elements has changed when the toolkit has popped up.

Avoid using any hyperlinks or any other actionable elements (apart from that close button) inside the tooltip. A tooltip should provide a brief explanation in plain text. If you need any links or buttons inside the tooltip, it is not a tooltip any more. You may need to rethink how the information is laid out on the screen, and chose a more appropriate mechanisms such as dialogues, expansion panels and such.


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.


Tooltip display when an actionable item is focused is fine. There are NO warnings otherwise about it in Success Criterion 1.4.13. What you do not want to do is have any actionable items within the tooltip since tooltips cannot receive focus.

When a keyboard user moves focus to another item the tooltip can be closed or a key (usually ESC) can close the tooltip.

For mouse users, they should be able to move the pointer between the tooltip trigger and the tooltip without the tooltip going away.

If you need a link or other actionable item in the tooltip consider using a dialog or toggle content.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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