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

Proposal for 1 TAB per chart keyboard navigation #6886

Closed
bvancea opened this Issue Jun 21, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@bvancea

bvancea commented Jun 21, 2017

Context

The current keyboard navigation pattern offered by the accessibility module is the following:

  • when tabbing to a chart, focus first moves to the chart container, which has the aria role of region.
  • when focus is inside this container, both TAB and ARROW keys can be used to move focus between chart elements (slices in a pie, bars in a barchart, points on line charts).

While this approach does provide flexibility for keyboard navigation, I have seen some issues on dashboard-like pages, which have many complex charts. In this case, the user really needs many tab stops to traverse the page.

I understand that there is a possibility to use landmark or heading navigation to skip over a chart with many points, but these shortcuts only work if a screen reader is ON. Users which use only the keyboard, and no screen readers will still have issues tabbing through tens or hundreds of chart elements.

Proposal

I propose adding an alternative keyboard navigation mode to the accessibility module. This mode can be toggled through a setting in the accessibility.keyboard settings object, called tabNavigationBetweenElements. This setting would toggle whether TAB navigates between chart elements, or skips to the next focusable elements on the page.

The behavior for all states of the new setting:

  • tabNavigationBetweenElements: true maintains the current keyboard navigation.
  • tabNavigationBetweenElements: false will change keyboard navigation to the following pattern: TAB focuses the chart container, and a next TAB jumps over all chart elements and focuses the next focusable element on the page. When the chart container is focused, arrow keys can be used to navigate between chart elements.

Implementation details

  1. Update the keydownHandler function to always 'slip' tabs in case tabNavigationBetweenElements is false.
  2. Apply role='application' on the chart.renderTo container node, instead of the region role. This should ensure that the screen reader specific keybindings will no longer interact with our custom arrow navigation.

What do you think about the idea? I tried the explained changes in a project, and then tested in JAWS + IE11 and Narrator + Microsoft Edge. I can also test on more configurations, even mobile VoiceOver and TalkBack (for mobile, we would mostly check the effects of role='application'.

I can open a PR with the proposal, but I wanted to see how the idea is received.

@KacperMadej

This comment has been minimized.

Show comment
Hide comment
@KacperMadej

KacperMadej Jun 21, 2017

Contributor

Hi,

Thank you for submitting the idea. Generally we are recommending userVoice for submitting enhancement ideas as we are trying to keep github for bugs.

@oysteinmoseng

Contributor

KacperMadej commented Jun 21, 2017

Hi,

Thank you for submitting the idea. Generally we are recommending userVoice for submitting enhancement ideas as we are trying to keep github for bugs.

@oysteinmoseng

@oysteinmoseng

This comment has been minimized.

Show comment
Hide comment
@oysteinmoseng

oysteinmoseng Jun 23, 2017

Collaborator

@bvancea Thank you for your suggestion and detailed proposal. I like the idea of letting tabs for points be optional, and will add this functionality shortly. There is already a transformTabs property for keyboard navigation modules, so this is not much work in itself. There is however an issue with Stock and Map charts, as these have navigation elements that can only be navigated by tab (Range selector for Stock, and Zoom buttons for map). This is because the arrow keys are used in combination with these features to control different behavior (panning for maps, text input for Range Selector). For now, I will try to restructure the navigation code in order to more easily disable or alter navigation for these modules from outside Highcharts. This will allow some more flexibility for plugins as well.

role="application" is in my opinion an unrelated subject, and should not be controlled by this same option. What is the context for requiring this? It will change the default behavior and likely be confusing for most screen reader users, as they will need to use left/right instead of up/down arrows to move between adjacent points.

Collaborator

oysteinmoseng commented Jun 23, 2017

@bvancea Thank you for your suggestion and detailed proposal. I like the idea of letting tabs for points be optional, and will add this functionality shortly. There is already a transformTabs property for keyboard navigation modules, so this is not much work in itself. There is however an issue with Stock and Map charts, as these have navigation elements that can only be navigated by tab (Range selector for Stock, and Zoom buttons for map). This is because the arrow keys are used in combination with these features to control different behavior (panning for maps, text input for Range Selector). For now, I will try to restructure the navigation code in order to more easily disable or alter navigation for these modules from outside Highcharts. This will allow some more flexibility for plugins as well.

role="application" is in my opinion an unrelated subject, and should not be controlled by this same option. What is the context for requiring this? It will change the default behavior and likely be confusing for most screen reader users, as they will need to use left/right instead of up/down arrows to move between adjacent points.

@oysteinmoseng

This comment has been minimized.

Show comment
Hide comment
@oysteinmoseng

oysteinmoseng Jun 23, 2017

Collaborator

I added an option accessibility.keyboardNavigation.tabThroughPoints which should help you out here. Example: http://jsfiddle.net/oysteinmoseng/37e43b75/. Note that you can now easily alter and modify the keyboard navigation modules for each chart element by accessing chart.keyboardNavigationModules and looking for the id property of the module you want to change. There is an example of this at the end of the demo above, removing the legend navigation entirely.

Still keeping this open until we have clarified the role="application" issue.

Collaborator

oysteinmoseng commented Jun 23, 2017

I added an option accessibility.keyboardNavigation.tabThroughPoints which should help you out here. Example: http://jsfiddle.net/oysteinmoseng/37e43b75/. Note that you can now easily alter and modify the keyboard navigation modules for each chart element by accessing chart.keyboardNavigationModules and looking for the id property of the module you want to change. There is an example of this at the end of the demo above, removing the legend navigation entirely.

Still keeping this open until we have clarified the role="application" issue.

@bvancea

This comment has been minimized.

Show comment
Hide comment
@bvancea

bvancea Jun 26, 2017

@oysteinmoseng Thank you for the detailed explanation and for the quick response! I had a look at your changes and examples, they look great!

Now, regarding role='application':

  • I see your point, it is not necessary to add role='application' for the proposed changes, so we don't need to tie it to the current change.
  • The reason I suggested adding role='application' would be to try to unify the behavior of screen readers on the chart, and make it closer to the keyboard navigation patterns used when no screen reader is on. For example, JAWS navigates to the next element in the DOM using the DOWN arrow. I was thinking that a role='application' would make JAWS use the keyboard pattern defined by the accessibility module, instead of overriding it with custom behavior.

However, after your comment, I understand the adding role='application' is a change that would need a thorough investigation. I will do some testing and come up with a follow-up proposal if I find that this role will improve usability.

In the meantime, changes looks great, so I am fine with resolving the issue in the current state.

bvancea commented Jun 26, 2017

@oysteinmoseng Thank you for the detailed explanation and for the quick response! I had a look at your changes and examples, they look great!

Now, regarding role='application':

  • I see your point, it is not necessary to add role='application' for the proposed changes, so we don't need to tie it to the current change.
  • The reason I suggested adding role='application' would be to try to unify the behavior of screen readers on the chart, and make it closer to the keyboard navigation patterns used when no screen reader is on. For example, JAWS navigates to the next element in the DOM using the DOWN arrow. I was thinking that a role='application' would make JAWS use the keyboard pattern defined by the accessibility module, instead of overriding it with custom behavior.

However, after your comment, I understand the adding role='application' is a change that would need a thorough investigation. I will do some testing and come up with a follow-up proposal if I find that this role will improve usability.

In the meantime, changes looks great, so I am fine with resolving the issue in the current state.

@oysteinmoseng

This comment has been minimized.

Show comment
Hide comment
@oysteinmoseng

oysteinmoseng Jun 26, 2017

Collaborator

@bvancea Excellent, I will close this. Feel free to open a new issue for role="application" if you would like to discuss it further.

Collaborator

oysteinmoseng commented Jun 26, 2017

@bvancea Excellent, I will close this. Feel free to open a new issue for role="application" if you would like to discuss it further.

@JllyGrnGiant

This comment has been minimized.

Show comment
Hide comment
@JllyGrnGiant

JllyGrnGiant Jun 27, 2017

@oysteinmoseng
When is accessibility.keyboardNavigation.tabThroughPoints expected to be available? Will it be included in the v5.0.13 release?
My organization has a bug filed against my team related to unexpected tab order that could be remedied with this option.
Thanks!

JllyGrnGiant commented Jun 27, 2017

@oysteinmoseng
When is accessibility.keyboardNavigation.tabThroughPoints expected to be available? Will it be included in the v5.0.13 release?
My organization has a bug filed against my team related to unexpected tab order that could be remedied with this option.
Thanks!

@JllyGrnGiant

This comment has been minimized.

Show comment
Hide comment
@JllyGrnGiant

JllyGrnGiant Jun 27, 2017

It's strange to have both tab and arrow keys do navigation through the same chart elements, so I'm excited to see this new option that makes charts act a little more closely to something like radio button groups where you use arrows to move between options and tabbing moves between groups.

@oysteinmoseng I'm encountering some unexpected navigation issues with relation to legends in a few places after trying out the new option.

https://codepen.io/anon/pen/MoOLQa

#####Scenario 1:

  1. Tab to chart
  2. Right arrow through chart to give focus to the "Jaws" legend item
  3. Press left arrow key
    1. Notice focus appears to have stayed on "Jaws" legend item
  4. Press right arrow key
    1. Notice focus jumped to the "Jaws" pie slice instead of the expected which would be to go to the "ZoomText" legend item

#####Scenario 2:

  1. Tab to chart
  2. Press right arrow to give focus to the "Jaws" pie slice
  3. Press left arrow
    1. Notice it isn't clear where focus went (seems to still be on "Jaws" slice)
  4. Press left arrow again which puts focus on "Other" pie slice
  5. Press right arrow key
    1. Notice focus goes to "Jaws" legend item instead of where you just came from, the "Jaws" pie slice

#####Scenario 3:

  1. Tab to chart
  2. Right arrow through chart to give focus to the "Other" legend item
  3. Press right arrow once more
    1. Notice it isn't clear where focus went (appears to still be on "Other" legend item)
  4. Press left arrow again which puts focus on "Other" pie slice
  5. Press left arrow key once more
    1. Notice focus goes to "Other" pie slice instead of the "Chrome Vox" legend item as expected

An ask I have is to change how users reach and navigate legend items as well.

I think it would make most sense for tabbing to go through the following ordering in my example:

  1. Entire chart
  2. Last focused pie chart
  3. Last focused label item
  4. Next focusable item on the page

Arrows would then be used to walk through each "group" where the chart itself is a group, the legend items are a group, etc. This would make it very easy for a keyboard user to tab past the entire chart or navigate to particular components they care about, such as the legend, without having to make their way through hundreds of points in a chart.

It would also fix the scenarios I listed above by keeping arrow navigation among legend items and the chart items separated.

JllyGrnGiant commented Jun 27, 2017

It's strange to have both tab and arrow keys do navigation through the same chart elements, so I'm excited to see this new option that makes charts act a little more closely to something like radio button groups where you use arrows to move between options and tabbing moves between groups.

@oysteinmoseng I'm encountering some unexpected navigation issues with relation to legends in a few places after trying out the new option.

https://codepen.io/anon/pen/MoOLQa

#####Scenario 1:

  1. Tab to chart
  2. Right arrow through chart to give focus to the "Jaws" legend item
  3. Press left arrow key
    1. Notice focus appears to have stayed on "Jaws" legend item
  4. Press right arrow key
    1. Notice focus jumped to the "Jaws" pie slice instead of the expected which would be to go to the "ZoomText" legend item

#####Scenario 2:

  1. Tab to chart
  2. Press right arrow to give focus to the "Jaws" pie slice
  3. Press left arrow
    1. Notice it isn't clear where focus went (seems to still be on "Jaws" slice)
  4. Press left arrow again which puts focus on "Other" pie slice
  5. Press right arrow key
    1. Notice focus goes to "Jaws" legend item instead of where you just came from, the "Jaws" pie slice

#####Scenario 3:

  1. Tab to chart
  2. Right arrow through chart to give focus to the "Other" legend item
  3. Press right arrow once more
    1. Notice it isn't clear where focus went (appears to still be on "Other" legend item)
  4. Press left arrow again which puts focus on "Other" pie slice
  5. Press left arrow key once more
    1. Notice focus goes to "Other" pie slice instead of the "Chrome Vox" legend item as expected

An ask I have is to change how users reach and navigate legend items as well.

I think it would make most sense for tabbing to go through the following ordering in my example:

  1. Entire chart
  2. Last focused pie chart
  3. Last focused label item
  4. Next focusable item on the page

Arrows would then be used to walk through each "group" where the chart itself is a group, the legend items are a group, etc. This would make it very easy for a keyboard user to tab past the entire chart or navigate to particular components they care about, such as the legend, without having to make their way through hundreds of points in a chart.

It would also fix the scenarios I listed above by keeping arrow navigation among legend items and the chart items separated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment