Skip to content

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

Merged
merged 4 commits into from
Jan 22, 2025

Conversation

anmazz
Copy link
Contributor

@anmazz anmazz commented Aug 22, 2024

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.

@anmazz anmazz marked this pull request as ready for review August 22, 2024 22:10
@anmazz anmazz changed the title Remove button type requirement Remove button type requirement on tooltips Aug 22, 2024
@brunerae brunerae requested review from amyleadem and mejiaj August 26, 2024 13:59
@amyleadem amyleadem added this to the uswds 3.10.0 milestone Sep 3, 2024
@amyleadem amyleadem changed the title Remove button type requirement on tooltips USWDS - Tooltip: Remove button type requirement Oct 22, 2024
@amyleadem amyleadem removed this from the USWDS release: December 2024 milestone Oct 31, 2024
@amyleadem amyleadem changed the title USWDS - Tooltip: Remove button type requirement USWDS - Tooltip: Allow tooltips on non-button elements Jan 3, 2025
@amyleadem amyleadem requested a review from a team as a code owner January 3, 2025 22:35
Copy link
Contributor

@amyleadem amyleadem left a 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;
Copy link
Contributor

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.

Copy link

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.

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.

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.

Copy link

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.

Copy link
Contributor

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

Copy link

@jaclinec jaclinec left a 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!

Copy link

@amycole501 amycole501 left a 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.

Copy link
Contributor

@mejiaj mejiaj left a 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.

Copy link
Contributor

@amyleadem amyleadem left a 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.

Copy link

@amycole501 amycole501 left a 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.

@amyleadem
Copy link
Contributor

@anmazz,
For security reasons, USWDS now requires that all commits to this repo have a verified signature. Your commits are registering as unverified, so we will need you to complete the following steps before this contribution can be merged:

  1. Set up signature verification in GitHub. Use one of the following GitHub guides to set up your verification signature:

  2. Rebase your commits with your verified signature. Once your signature is set up, complete the following steps in the terminal to update the verification status of your previous commits:

    git checkout branch-name
    git rebase origin/main
    git push --force-with-lease
    

Thanks again for your contribution. Please let us know if you have any questions or if we can help in any way.

@anmazz anmazz force-pushed the tooltip-all-elements branch from 039f140 to d815b58 Compare January 7, 2025 20:08
@anmazz
Copy link
Contributor Author

anmazz commented Jan 7, 2025

@anmazz, For security reasons, USWDS now requires that all commits to this repo have a verified signature. Your commits are registering as unverified, so we will need you to complete the following steps before this contribution can be merged:

  1. Set up signature verification in GitHub. Use one of the following GitHub guides to set up your verification signature:

  2. Rebase your commits with your verified signature. Once your signature is set up, complete the following steps in the terminal to update the verification status of your previous commits:

    git checkout branch-name
    git rebase origin/main
    git push --force-with-lease
    

Thanks again for your contribution. Please let us know if you have any questions or if we can help in any way.

Done! For future reference, the command should be git rebase origin/develop

mejiaj pushed a commit to uswds/uswds-sandbox that referenced this pull request Jan 14, 2025
Copy link
Contributor

@thisisdano thisisdano left a 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

@thisisdano thisisdano merged commit 756b82d into uswds:develop Jan 22, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

USWDS - Bug: Tooltip documentation claims the tooltip component applies to any element; it only applies to buttons
7 participants