-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Table Column Resize via screen readers #3295
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
Conversation
Build successful! 🎉 |
Build successful! 🎉 |
changed resizer to input w/ onChange since Android Talkback doesnt fire keyboad events when swiping up/down. aria-valuemax Infinitiy breaks android talkback slider interactions
Build successful! 🎉 |
Build successful! 🎉 |
Build successful! 🎉 |
Build successful! 🎉 |
# Conflicts: # packages/@react-aria/table/src/useTableColumnHeader.ts # packages/@react-aria/table/src/useTableColumnResize.ts # packages/@react-spectrum/table/src/Resizer.tsx # packages/@react-spectrum/table/src/TableView.tsx
# Conflicts: # packages/@react-aria/table/src/useTableColumnResize.ts
Build successful! 🎉 |
Build successful! 🎉 |
# Conflicts: # packages/@react-aria/table/src/useTableColumnResize.ts # packages/@react-spectrum/table/package.json # packages/@react-spectrum/table/src/TableView.tsx
Build successful! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested a few tables with OSX Chrome VO and this worked nicely.
Build successful! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM on VO. I did see the large number read off you mentioned
Build successful! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some things I noted when testing:
- The resize handles don’t appear after tapping the “Resize column” menu option in Android
- Only happen in the storybook iframe, works fine if it is outside the iframe
- Pretty hard to drag the handles in mobile but that will be handled in followups
- Unable to confirm a resize operation when double tapping in VoiceOver sometimes (happened with “File Name” column in the “some columns not allowed resizing story”). Other times double tapping will cause a shift in position before confirming the resize operation
onMouseDown: (e: React.MouseEvent<HTMLElement>) => { | ||
if (e.button !== 0 || e.altKey || e.ctrlKey || e.metaKey) { | ||
return; | ||
} | ||
onDown(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing these are used instead of usePress because of the extra conditional early returns? Seems to be a pretty common pattern that is cropping up, might be something we could add to usePress as an option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is copied from the slider code
which is track listener code, so this may not be necessary? https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/slider/src/useSlider.ts#L198
I'll double check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry i linked the wrong one, ignore my previous comment, it's from slider thumb
https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/slider/src/useSliderThumb.ts#L212 which makes more sense
I've switched to usePress and it appears to work just fine. It may just be old code that needed altKey etc before that existed in the PressEvent and keyboard was already covered elsewhere and usePress would double that coverage
// focusSafely won't actually focus because the focus moves from the menuitem to the body during the after transition wait | ||
resizingRef.current.focus(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe linked to the weird The resize handles don’t appear after tapping the “Resize column” menu option in Android in storybook iframe
behavior I noted. I can try poking around
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the issue goes away if I wrap this focus in a setTimeout,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hahaha, but in a RAF it was failing for me
Build successful! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't seem to confirm a resize operation via Voiceover now, not entirely sure how the changes broke that hrm
Build successful! 🎉 |
if (e.pointerType === 'virtual' && columnState.currentlyResizingColumn != null) { | ||
stateRef.current.onColumnResizeEnd(item); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed that double tapping to trigger a press on the visually hidden input via VO and Talkback now "confirm"/exit the resize operation, but there seems to be an issue in Android Chrome now where the focus is lost to the body upon triggering the press. VO is a bit better but it suffers from an issue where the press happens on the element under the visually hidden input which could be an entirely different column depending on how much resizing happened.
What if you have move focus to the column header in this case instead since the resize handles go away? I'm fine with handling this in a followup or after we confirm the overall behavior with accessibility if you'd like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Focus should be moving to the header on column resize end, so I'm not sure what you're seeing. Maybe we can hop on a call tomorrow and discuss it more.
Build successful! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested w/ Rob, Android Chrome and VoiceOver issues have been resolved
columnHeaderProps: { | ||
...mergeProps(gridCellProps, pressProps, focusableProps, descriptionProps), | ||
...mergeProps(gridCellProps, pressProps, focusableProps, descriptionProps, { | ||
onPointerDown: (e) => console.log(e.target.outerHTML) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume this was not meant to go in.
isVirtualized?: boolean | ||
isVirtualized?: boolean, | ||
/** Whether the column has a menu in the header, this changes interactions with the header. */ | ||
hasMenu?: boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be less specific to menus? Should it be more like an override to disable the default sorting behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, what are the use cases other than a menu where we'd want to disable the default sorting behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, but I mainly wondered if menus were too spectrum-specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe, it was the ask for a future feature, custom menu options on columns. so that's where the name came from. I'm fine changing it though to disableDefaultSort
or disableDefaultInteraction
?
Closes #3028
Splits the MenuTrigger from the Header. This makes for some better more reasonable styling and should improve screen reader announcements as well.
I've changed the role=separator to an input type=range, just changing to slider wasn't enough, TalkBack wouldn't fire onChange events with swipe gestures. This brings it more in line with SliderThumb. (See https://github.com/adobe/react-spectrum/blob/main/packages/%40react-spectrum/slider/src/SliderThumb.tsx#L46 for rendering and https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/slider/src/useSliderThumb.ts#L179 for aria similarities)
As a result, I've been able to simplify the aria-* attributes on the input, some styling needed changes as well to compensate for the new structure.
I've included a new prop to useTableColumnHeader, optional so backwards compatible, non-breaking
hasMenu
which will help us in the future when we allow people to pass in their own menu items. It also removes knowledge of resizing from useTableColumnHeader.I've hooked up all the id's for better screen reader announcements, the resizer will now be labelled by the column header. This helps with the entire table announcing again as well.
I've limited the max value of the width from Infinity to the max safe integer, that's all we can really support anyways, and a max value of Infinity causes TalkBack to stop firing onChange.
Open issues:
There is an issue where VO reads off a large negative number when focusing the resizer that I haven't been able to solve yet.
FF still doesn't display focus ring for mouse users
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: