-
-
Notifications
You must be signed in to change notification settings - Fork 777
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
Basic slider accessibility #282
Basic slider accessibility #282
Conversation
Oops, CI failed |
@byCedric |
@paranoidjk thanks! Yeah, of course, I have some time late tonight. I think I can have this done tomorrow morning, around 08:00 (GMT) or something like that. |
@paranoidjk Ok, so I rebased and added the tabindex to the handlers within the snapshots. Can I help with something for the final merge? |
👍 It will be better if you can add unit test for this new feature. |
|
||
case keyCode.END: return (value, props) => props.max; | ||
case keyCode.HOME: return (value, props) => props.min; | ||
case keyCode.PAGE_UP: return (value, props) => value + props.step * 2; |
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.
why * 2
?
as you described in #131 (comment), peg_up should be equal with up
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.
For the up and down behaviours I tend to follow the Polymer approach. Mainly because you are "upping" or "downing" the current value.
What I tried to explain was that I like how Polymer's approach had the same type of behaviour with both up
and pageup
keys. Both "up" keys increased the current value. OAA's behaviour was the same for up
and pagedown
, which I didn't like because of mixed "up" and "down" keys.
Later on I tried to reason that OAA has a point about the increased value jump through pageup
and pagedown
. For small sliders it makes no different, but if you have a big one you would probably want to go faster through the steps.
OAA Accessibility has a point about the page up and page down behaviours. I mean, left/down and up/right only go by 1 step. For small sliders this is fine, but for large ones not. Also if an user actually uses the page up/page down key, they probably expect something more then just a mimick of left and right.
I'm open for both approaches. Either increase the step when using the page keys or just copy the same behaviour from the normal up/down keys. It's up to you guys.
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.
Ok, i understand. But please make sure you update the api doc in readme correctly.
if (valueMutator) { | ||
utils.pauseEvent(e); | ||
const state = this.state; | ||
const oldValue = state.value; |
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.
no need to define a variable state
?
const { value: oldValue } = this.state;
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.
If it was up to me, I would have definitely used these destructuring assignment. But I didn't want to introduce a new code styling. That's why I sticked as close as possible to the existing one. I think I based this part of the code on this code.
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.
😅 no need to obey current code style, just use what you think is better.
It's just because that we do not have enough time to refactor this component right now, and PR is welcome ~
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.
Haha, good to know! Let's keep this for now unchanged. If I have some time again after this PR, I will try to create one for some refactoring 😄
if (utils.isEventFromHandle(e, this.handlesRefs)) { | ||
const handlePosition = utils.getHandleCenterPosition(isVertical, e.target); | ||
|
||
this.dragOffset = 0; |
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.
Why set dragOffset
to zero?
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 think I did this to "reset" mouse/touch behaviours when combining keyboard with these. But I'm not sure if this is even necessary. Just tested with and without this and I had the same outcome... I can remove it if you want?
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 think we can keep it, since this.dragOffset = 0;
is to restore drag status.
@byCedric |
Yeah, sure! I will try to start on that tonight! |
ping~ @byCedric |
Hey guys, sorry it took a while to respond. I tried to write some tests for the slider first, but quickly encountered some errors. For example, this is the most simple test I've written. it('increments the value when key "up" was pressed', () => {
const wrapper = mount(<Slider value={50} step={1} />);
const handler = wrapper.find('.rc-slider-handle');
handler.simulate('focus');
handler.simulate('keyDown', { keyCode: keyCode.UP });
expect(wrapper.state('value')).toBe(51);
}); I think this should work right? But It gives me this error. $ npm test
> rc-slider@8.1.5 test /absolute/path/to/slider
> jest
FAIL tests/Slider.test.js
● Slider › increments the value when up key was pressed
TypeError: Cannot read property 'toFixed' of undefined
at Object.ensureValuePrecision (src/utils.js:75:2549)
at ComponentEnhancer.trimAlignValue (src/Slider.jsx:127:20)
at ComponentEnhancer.calcValueByPos (src/common/createSlider.jsx:224:1870)
at ComponentEnhancer.onStart (src/Slider.jsx:85:1605)
at ComponentEnhancer._this.onFocus (src/common/createSlider.jsx:130:45)
at Object.invokeGuardedCallback [as invokeGuardedCallbackWithCatch] (node_modules/react-dom/lib/ReactErrorUtils.js:26:5)
at executeDispatch (node_modules/react-dom/lib/EventPluginUtils.js:83:21)
at Object.executeDispatchesInOrder (node_modules/react-dom/lib/EventPluginUtils.js:108:5)
at executeDispatchesAndRelease (node_modules/react-dom/lib/EventPluginHub.js:43:22)
at executeDispatchesAndReleaseSimulated (node_modules/react-dom/lib/EventPluginHub.js:51:10)
at forEachAccumulated (node_modules/react-dom/lib/forEachAccumulated.js:26:8)
at Object.processEventQueue (node_modules/react-dom/lib/EventPluginHub.js:252:7)
at node_modules/react-dom/lib/ReactTestUtils.js:351:22
at ReactDefaultBatchingStrategyTransaction.perform (node_modules/react-dom/lib/Transaction.js:143:20)
at Object.batchedUpdates (node_modules/react-dom/lib/ReactDefaultBatchingStrategy.js:62:26)
at Object.batchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:97:27)
at node_modules/react-dom/lib/ReactTestUtils.js:349:18
at ReactWrapper.<anonymous> (node_modules/enzyme/build/ReactWrapper.js:776:11)
at ReactWrapper.single (node_modules/enzyme/build/ReactWrapper.js:1421:25)
at ReactWrapper.simulate (node_modules/enzyme/build/ReactWrapper.js:769:14)
at Object.<anonymous> (tests/Slider.test.js:29:13)
at handle (node_modules/worker-farm/lib/child/index.js:41:8)
at process.<anonymous> (node_modules/worker-farm/lib/child/index.js:47:3)
at emitTwo (events.js:125:13)
at process.emit (events.js:213:7)
at emit (internal/child_process.js:768:12)
at _combinedTickCallback (internal/process/next_tick.js:141:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
PASS tests/common/createSlider.test.js
PASS tests/common/marks.test.js
PASS tests/Range.test.js
Test Suites: 1 failed, 3 passed, 4 total
Tests: 1 failed, 1 skipped, 22 passed, 24 total
Snapshots: 3 passed, 3 total
Time: 5.482s
Ran all test suites.
npm ERR! Test failed. See above for more details. Any idea how to fix this? Or do you need actual code for this? @benjycui |
@byCedric can you re-produce this with |
Please push your test code to this pr, i'd like to help you figure out the problem. And please make sure you do have rebased |
Yeah, will do tonight. I'll start with the tests for the slider. It looks like I'm doing something wrong with trimming the value for keyboard events. But as I said, will rebase and add the slider tests tonight! 👍 |
Ok guys, I did a final effort in debugging what goes wrong. I found out that when focusing the handler directly, as coded in the example, the slider thinks he is exactly Right now I'm patching up the other tests, I'll commit it soon afterwards! |
So what do you guys think about this, any tips/tricks I should do? I think there could be some improvements within the tests by e.g. grouping them. Or even automate some repeating tests by iterations, instead of hardcoding it. Anyways, I'm still a bit puzzled why I need to use both the |
Oh wait, I see I changed a line I shouldn't have. |
Thanks for @byCedric 👍 Released |
@paranoidjk PR to antd is welcomed. |
@benjycui What do you mean? antd should be no need to do any change, right? |
https://github.com/ant-design/ant-design/blob/master/package.json#L64 antd had locked minor |
As promptly discussed in issue #131, I created some basic accessibility for the Slider. I implemented the keyboard behaviour as my personal best guess of how it should work.