-
Notifications
You must be signed in to change notification settings - Fork 1k
USWDS - Tooltip: Allow tooltips on non-button elements #6035
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution @anmazz! This looks good to me from an engineering perspective.
- Confirm the tooltips work as expected on non-button elements
- Confirm no regressions in tooltips on button elements
- Confirm code updates make sense and meet USWDS standards
- Confirm the PR description is up to date and accurate
- Note: I added a changelog for review
Open questions
Before approving, I would like the accessibility and usability team to weigh in on this change:
- @amycole501 and/or @alex-hull, can you confirm that the keyboard focus behavior works as expected in this test story? The tooltip dynamically add its parent elements to the
tabindex
and makes the otherwise non-interactive items focusable, and I just want to make sure that that is expected.- Note: This test branch was published at the time of this comment and might fall out of date. If any changes happen after this comment, we should update the test branch as well.
- @jaclinec can you confirm that the change to allow tooltip on non-button elements lines up with existing research and recommendations? Do we need to test this change with users before releasing this update?
@@ -379,10 +379,9 @@ const tooltip = behavior( | |||
"mouseover focusin": { | |||
[TOOLTIP](e) { | |||
const trigger = e.target; | |||
const elementType = trigger.nodeName; |

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note
I confirmed that the elementType
variable is not referenced anywhere else in the file, so this is safe to remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't done any research on allowing tooltips on non-button elements but Amy C has - @amycole501 could you weigh in on whether this change is in alignment with your research findings?
We are testing tooltips on static icons in the next round of usability testing slated for late Jan-early Feb. It seems like this enhancement is needed in the community, so I don't want to hold up implementation. I'd say we could probably move forward with the change and then if we see any issues in testing we could course-correct later. This might be a call for @thisisdano to make.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test story focus works as expected. And yes, other design systems and interactions support using a tooltip on non-button-designed elements. The primary thing to do is ensure the non-button element (such as an "i" icon) is focusable and in the tab order as any other interactive item. That way keyboard and screen reader users can gain insight into what's in the tooltip instead of using the hover option.
Here's a link to my research.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with NVDA and JAWS. My one thing we should probably consider is adding the word "tooltip" before the tooltip is actually read. With the screen readers, it sounds like a set of words not associated with the specific item. Other than that, I think it would be safe with moving on with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alex-hull we are testing that in the next round of usability testing and it's being work on in #5891. I wasn't sure if we want to fully implement it BEFORE testing or if we want to wait for testing results to do it. At the very least it needs to be testable in the prototype.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm comfortable releasing this as-is and possibly constraining in the future we we learn more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to officially add my review - I already commented but LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @alex-hull about adding "tooltip" to give context to the content inside the tooltip.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, thanks for the contribution!
The a11y concerns on non-focusable elements were addressed in this comment and aren't a blocker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
All UX/accessibility concerns appear to have been addressed in this comment thread and this Slack thread (🔒), and we will follow-up by investigating if more screen reader context is needed for tooltips in #5891.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good- we have an issue elsewhere to cover the announcement of "tooltip" so this is good to go.
@anmazz,
Thanks again for your contribution. Please let us know if you have any questions or if we can help in any way. |
039f140
to
d815b58
Compare
Done! For future reference, the command should be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! And thank you for improving our verified commits instructions
Summary
Removes the
elementType === "BUTTON"
for tooltip initialization to allow other elements, such as svgs, to have tooltips.Breaking change
Not a breaking change.
Related issue
Closes #5190
Related PR
Changelog PR
Preview link
Preview link: (Unsure how to link storybooks)
Problem statement
Tooltips were not attaching to other elements such as icons/svgs. The current implementation also did not match with current documentation.
Solution
Removed element type check of type button.
Testing and review
Added new twig file.