Skip to content
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

Persistent Hover Accessibility Guideline #2088

Open
2 tasks done
jpc98 opened this issue Feb 9, 2022 · 4 comments
Open
2 tasks done

Persistent Hover Accessibility Guideline #2088

jpc98 opened this issue Feb 9, 2022 · 4 comments
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Enhancement ✏️ An enhancement or feature proposal that will be addressed after the next release

Comments

@jpc98
Copy link

jpc98 commented Feb 9, 2022

Feature Requests

Checklist

  • I've read through the Docs and Guides to make sure this functionality doesn't already exist

  • I've searched open issues to make sure I'm not opening a duplicate issue

Description

The WCAG guidelines have the following criteria for hover bubbles:
https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
Relevant text quoted below:

Hoverable
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

This is not met by the hover tooltips provided by VictoryChart currently - when hovering over the content that pops up, the content disappears since the user is no longer hovering over the relevant point.

@matt-hernandez
Copy link
Contributor

@jpc98 This issue looks like it can be solved by nesting your data inside a <VictoryChart> component that also uses <VictoryVoronoiContainer> as the value of the containerComponent prop. Then you can manually use <VictoryTooltip> as the labelComponent prop of your data viz of choice. This should allow for a mouse to move from data point to tooltip without the tooltip disappearing.

<VictoryChart domainPadding={{ y: 10, x: 20 }}
  containerComponent={
    <VictoryVoronoiContainer/>
  }
>
<VictoryBar
  data={sampleData}
  labels={() => "HELLO"}
  labelComponent={
    <VictoryTooltip
      center={{ x: 225, y: 30 }}
      pointerOrientation="bottom"
      flyoutWidth={150}
      flyoutHeight={50}
      pointerWidth={150}
      cornerRadius={0}
    />
  }
/>
</VictoryChart>

@jpc98
Copy link
Author

jpc98 commented Feb 22, 2022

Thanks for the suggested solution! This feels more like a workaround to me, and it may be worth considering making this feature standard for victory's tooltips rather than relying on consumers to implement a VoronoiContainer for the tooltips to meet the standard. But definitely lower priority since there's a way around it!

@matt-hernandez
Copy link
Contributor

I wonder if it may be best to control this behavior with a prop, maybe something like a persistent prop on the Tooltip component. The reason being that if a chart has a lot of points of interest, it may be desired behavior for the tooltip to vanish if the mouse moves off the data point. Making it standard by default could cause problems for existing users who upgrade

@jpc98
Copy link
Author

jpc98 commented Feb 22, 2022

Maybe an override would make sense, but I do think we'd want the default to be meeting the accessibility guideline if at all possible, since that's the reason that guideline exists in the first place! The tooltip vanishing may be desired behavior, but it's also a problematic behavior for users using certain kinds of assistive technology.

That said, I realize this is the sort of change that could lead to a worse experience for certain use cases, so an override of some sort would make sense as long as the accessibility implications were documented. That way the site still behaves as originally intended until a more accessible design can be implemented without making the application difficult to use.

@carbonrobot carbonrobot added Type: Enhancement ✏️ An enhancement or feature proposal that will be addressed after the next release Issue: Accepted The submitted issue has been confirmed by the Victory core team labels Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Enhancement ✏️ An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

No branches or pull requests

5 participants