Skip to content
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

Merged
merged 8 commits into from
Jul 28, 2017
Merged

Basic slider accessibility #282

merged 8 commits into from
Jul 28, 2017

Conversation

byCedric
Copy link
Contributor

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.

Note, this is a work in progress but I wanted to share my changes already.

@benjycui
Copy link
Member

Oops, CI failed

@paranoidjk
Copy link
Member

@byCedric
Thanks for your pr, Wonderful job 👍
Could you please rebase master to solve the conflict and fix the ci, then i will do a code review.

@byCedric
Copy link
Contributor Author

byCedric commented Jul 3, 2017

@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 paranoidjk self-assigned this Jul 4, 2017
@coveralls
Copy link

Coverage Status

Coverage decreased (-5.8%) to 43.558% when pulling d99adb9 on byCedric:feature/accessibility into 9c0ea63 on react-component:master.

@byCedric
Copy link
Contributor Author

byCedric commented Jul 4, 2017

@paranoidjk Ok, so I rebased and added the tabindex to the handlers within the snapshots. Can I help with something for the final merge?

@benjycui
Copy link
Member

benjycui commented Jul 5, 2017

👍

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;
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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;
Copy link
Member

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;

Copy link
Contributor Author

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.

Copy link
Member

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 ~

Copy link
Contributor Author

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;
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

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.

@paranoidjk
Copy link
Member

@byCedric
We almost done. Please update the api doc on readme, and add some test case, you can take a look at the existing testcase in /tests folder.

@byCedric
Copy link
Contributor Author

byCedric commented Jul 8, 2017

Yeah, sure! I will try to start on that tonight!

@benjycui
Copy link
Member

ping~ @byCedric

@byCedric
Copy link
Contributor Author

byCedric commented Jul 26, 2017

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

@benjycui
Copy link
Member

@byCedric can you re-produce this with master branch?

@paranoidjk
Copy link
Member

@byCedric

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 master.

@byCedric
Copy link
Contributor Author

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! 👍

@byCedric
Copy link
Contributor Author

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 0px wide. The strange thing is that when I focus the wrapper first, and then fire a KeyboardEvent on the handler, everything works. This looks like it needs some extra caring and love, but for now I'm not going in to deep.

Right now I'm patching up the other tests, I'll commit it soon afterwards!

@coveralls
Copy link

Coverage Status

Coverage increased (+4.05%) to 53.374% when pulling b8155a4 on byCedric:feature/accessibility into 9c0ea63 on react-component:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+4.05%) to 53.374% when pulling 6a448fd on byCedric:feature/accessibility into 9c0ea63 on react-component:master.

@byCedric
Copy link
Contributor Author

byCedric commented Jul 27, 2017

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 wrapper and handler for focus and keyboard event. Maybe you can shine your lights on that one @paranoidjk?

@byCedric
Copy link
Contributor Author

Oh wait, I see I changed a line I shouldn't have.

@coveralls
Copy link

Coverage Status

Coverage increased (+4.05%) to 53.374% when pulling c6fde1d on byCedric:feature/accessibility into 9c0ea63 on react-component:master.

@paranoidjk paranoidjk merged commit 59a5b15 into react-component:master Jul 28, 2017
@paranoidjk
Copy link
Member

Thanks for @byCedric 👍 Released rc-slider@8.3.0

@benjycui
Copy link
Member

@paranoidjk PR to antd is welcomed.

@paranoidjk
Copy link
Member

@benjycui What do you mean? antd should be no need to do any change, right?

@benjycui
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants