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
After choosing "Keyboard Column Resizing" in the columnheader menu, keyboard focus moves back up to document.body (the default focus target when a focused element is removed without actively moving focus somewhere else). When it does so, both a screen reader user's cursor, and a magnification user's view would jump back up to the top of the document.
In addition to that, arrow keys resize the column no matter what element is currently in focus.
Expected behavior:
If we continue with this approach, focus should return to the columnheader that the menu was triggered from, and arrow keys should only resize the column when that specific columnheader is in focus.
In general, I think we should rethink the approach a bit -- there's no feedback on what's going on as you resize, or information on how to resize after choosing the menu item. My initial thought would be to both implement something like a keyboard shortcut (ctrl + brackets, for example) and a context menu that lists the keyboard shortcut and also has a way to directly input a new width as text. The latter would work for people who are not using the keyboard, but might have issues resizing with a mouse for any reason.
The text was updated successfully, but these errors were encountered:
Describe the issue:
After choosing "Keyboard Column Resizing" in the columnheader menu, keyboard focus moves back up to
document.body
(the default focus target when a focused element is removed without actively moving focus somewhere else). When it does so, both a screen reader user's cursor, and a magnification user's view would jump back up to the top of the document.In addition to that, arrow keys resize the column no matter what element is currently in focus.
Expected behavior:
If we continue with this approach, focus should return to the columnheader that the menu was triggered from, and arrow keys should only resize the column when that specific columnheader is in focus.
In general, I think we should rethink the approach a bit -- there's no feedback on what's going on as you resize, or information on how to resize after choosing the menu item. My initial thought would be to both implement something like a keyboard shortcut (ctrl + brackets, for example) and a context menu that lists the keyboard shortcut and also has a way to directly input a new width as text. The latter would work for people who are not using the keyboard, but might have issues resizing with a mouse for any reason.
The text was updated successfully, but these errors were encountered: