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

[en] Developing a Keyboard Interface - More information about charts and interactive graphics - Feedback from APG List #3154

Open
lolaodelola opened this issue Oct 22, 2024 · 0 comments

Comments

@lolaodelola
Copy link

"Hi everyone,

My name is Abhinav Srinivasan and I work in the Graphics Interactions team at The MathWorks, the company that makes MATLAB.

Over the past few years I've been incorporating keyboard navigation and interactions to our various graphs and charts wherever it makes sense. I have found these ARIA Authoring Practices Guides invaluable in such cases - thank you! However, there are times when I find the broad principles described in them slightly insufficient, especially because interactive graphics and visualizations seems to warrant special attention that is not covered by the overall guidelines.

Here are some questions I have:

  1. What kind of patterns exist for interactions on a visualization? For example, the Button patternhttps://www.w3.org/WAI/ARIA/apg/patterns/button/ clearly specifies the keyboard interactions that must be followed (i.e. Space and Enter activate the button). However, how should one reason on what kinds of keys map best to interactions like pan, zoom, rotate, and adding/moving/removing datatips? How about complex interactions like data brushing and manipulation? There's not much by way of pattern that one can follow here.

  2. What is considered best practice on which graphical elements must receive focus? Typically I'd argue that only graphics elements that have keyboard interactions must receive focus. But I have heard arguments that giving focus even in the absence of keyboard interactions is useful for screen-reader support. However, for someone not using a screen-reader, who does rely on a keyboard interface, would the fact that both keyboard interactive and non-keyboard-interactive elements receiving focus be confusing?

These are just a couple of questions I have. I have a few more along these lines. I fully understand that not all of these questions may have clear cut answers. So I'm willing to participate and volunteer in any way that would be helpful for developing a more robust set of guidelines and patterns specifically focused on these kinds of problems pertaining to keyboard interactions in interactive graphics.

Please let me know if you have answers to any of the questions above. Also let me know how I can help. I look forward to hearing back from you soon.

Thanks"

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

No branches or pull requests

1 participant