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

fix(module:time-picker): make keyboard navigation possible #3145

Conversation

jimmytheneutrino
Copy link
Contributor

Tabbing away from time-picker overlay was not possible: It wrapped
around and usually ended up in browser's address bar. Also, once you
selected time-picker wrapper span, there was no way to open the overlay
via keyboard.
This fixes this. Tabbing away from overlay now focuses on time-picker
wrapper span. Pressing enter on the wrapper span opens the overlay.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Tabbing away from time-picker overlay was not possible: It wrapped
around and usually ended up in browser's address bar. Also, once you
selected time-picker wrapper span, there was no way to open the overlay
via keyboard.

Issue Number: N/A

What is the new behavior?

Tabbing away from overlay now focuses on time-picker
wrapper span. Pressing enter on the wrapper span opens the overlay.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

The behavior (both current and new) can be observed on the main demo page (npm run site:start).

@netlify
Copy link

netlify bot commented Mar 24, 2019

Deploy preview for ng-zorro-master ready!

Built with commit a594623

https://deploy-preview-3145--ng-zorro-master.netlify.com

@codecov
Copy link

codecov bot commented Mar 24, 2019

Codecov Report

Merging #3145 into master will decrease coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3145      +/-   ##
==========================================
- Coverage   95.39%   95.37%   -0.03%     
==========================================
  Files         712      706       -6     
  Lines       14633    14516     -117     
  Branches     1929     1915      -14     
==========================================
- Hits        13959    13844     -115     
  Misses        244      244              
+ Partials      430      428       -2
Impacted Files Coverage Δ
components/time-picker/nz-time-picker.component.ts 92.15% <100%> (+0.07%) ⬆️
...mponents/descriptions/nz-descriptions.component.ts 95.83% <0%> (-2.89%) ⬇️
components/message/nz-message.service.ts 97.95% <0%> (-2.05%) ⬇️
components/tabs/nz-tab.component.ts 96% <0%> (-0.56%) ⬇️
components/carousel/nz-carousel.component.ts 93.71% <0%> (-0.54%) ⬇️
components/input/nz-autosize.directive.ts 91.76% <0%> (-0.38%) ⬇️
components/tabs/nz-tabs-nav.component.ts 90.62% <0%> (-0.34%) ⬇️
components/core/wave/nz-wave-renderer.ts 88.23% <0%> (-0.18%) ⬇️
components/carousel/strategies/base-strategy.ts 96% <0%> (-0.16%) ⬇️
components/layout/nz-sider.component.ts 93.75% <0%> (-0.1%) ⬇️
... and 31 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab8a58c...a594623. Read the comment docs.

[(ngModel)]="value">
</nz-time-picker-panel>
<span tabindex=0 (focus)="close()" class="nz-tab-catching-span"></span>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why class "nz-tab-catching-span"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the syntax tabindex=0 should be tabindex="0"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why class "nz-tab-catching-span"?
So that it is easier to handle in the future (if there is need) plus it is a bit self-documenting.

Also the syntax tabindex=0 should be tabindex="0"
Ok. I will fix that.

@wilsoncook
Copy link
Member

Hi @jimmytheneutrino , we're very grateful for your work! It would be better to provide the actual usage scenario for this PR (as i think there is no need to handle the enter key on <input> only, unless we provide the full set of keyboard processing mechanisms such as "left/right arrow to select a specified time value").

@jimmytheneutrino
Copy link
Contributor Author

@wilsoncook
This onEnter is for the case when the user inputs values by hand using digits on the keyboard.
IMHO the user does not need any arrow key bindings when they already can input just digits.

@jimmytheneutrino
Copy link
Contributor Author

@wilsoncook
Hi! Do you need something else fixed?

@jimmytheneutrino
Copy link
Contributor Author

@wilsoncook Could you please tell me what else needs to be done?

@wenqi73
Copy link
Member

wenqi73 commented Jun 13, 2019

@jimmytheneutrino Thanks for your PR, this belongs to a11y (#1651) which contains full set of keyboard processing as @wilsoncook said, not just OnEnter. It will be helpful that if you provide a full solution of this component.

@jimmytheneutrino
Copy link
Contributor Author

@wenqi73 @wilsoncook
I understand that the full a11y solution would be preferable. Unfortunately, this seems to be a large task and I do not have time to do all of its nuances.

However, isn't a partial improvement better than no improvement? Please see the videos:
https://imgur.com/a/IhI9R6i .

I think that just this little bit could be a huge improvement in usability for some users.

[(ngModel)]="value">
</nz-time-picker-panel>
<span tabindex="0" (focus)="close()" class="nz-tab-catching-span"></span>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<span tabindex="0" (focus)="close()" class="nz-tab-catching-span"></span>

In theory the focus point should be moved to time picker panel when pressing Tab, it should not close the panel.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the same way as it is done in the react version: https://ant.design/components/time-picker/ ?

But I am sure this is a UX bug in that version. This behaviour would be completely unusable with a keyboard. You need to press tab about a hundred times to get anything done there. In reality, choosing time on the time-picker is not needed if the user is already using the keyboard.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The right way is: Users use Tab to toggle HOUR/MINITE/SECOND/INPUT selection, use UP_ARROW or DOWN_ARROW to select number.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really? In order to input the time this way in the worst case the user needs 12 + 30 + 30 keystrokes.
Why would anyone do it if they can just input time with numbers, press tab and go to the next input on the form? The way you propose the user would just have to press tab 3 times more to skip through those selections.

The way I see its usage is that:
a) there are some users who use mouse to enter time - and the time panel is great for that,
b) but there are some 'more experienced' users who want to do it faster -- and they could use keyboard for that -- 6 strokes+tab -- might take less than 2 seconds.
Imagine a receptionist somewhere who does it every day, hundreds of times.

Of course, one could implement a special form for the case b), but if the standard component could do it, why not try with a standard one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to support to cover everywhere of the panel only use keyboard, I mean use Tab to toggle when the panel is open, if user want to do it faster they can use 6 strokes + Enter + Tab to switch to next element, the Tab should not just close panel.

@@ -6,7 +6,8 @@
[placeholder]="nzPlaceHolder || ('TimePicker.placeholder' | nzI18n)"
[(ngModel)]="value"
readonly="readonly"
(click)="open()">
(click)="open()"
(keyup.enter)="open()">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add the tests about your changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added tests.

Tabbing away from time-picker overlay was not possible: It wrapped
around and usually ended up in browser's address bar. Also, once you
selected time-picker wrapper span, there was no way to open the overlay
via keyboard.
This fixes this. Tabbing away from overlay now focuses on time-picker
wrapper span. Pressing enter on the wrapper span opens the overlay.
@vthinkxie
Copy link
Member

@wenqi73 plz check this again

Copy link
Member

@wenqi73 wenqi73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavior of TAB key does not match our design.

@vthinkxie
Copy link
Member

As there is no update for a long time, the PR will be closed.
If you have any questions, feel free to open another PR, thanks a lot.

@vthinkxie vthinkxie closed this Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants