You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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"
The text was updated successfully, but these errors were encountered:
"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:
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.
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"
The text was updated successfully, but these errors were encountered: