Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding date form to date picker and improving accessibility #7621
Fixes issues related to issue #1311. The discussion on the ticket is extensive, but this should cover most of the complaints.
How has this been tested?
Types of changes
Accessibility and UI changes
referenced this pull request
Jun 28, 2018
This is cool! I left some little bits of code/style feedback.
I didn't try keyboard navigation yet; I'll leave that for @afercia since he filed the original issue and is an expert.
Thoughts on the design: it'd be nice if days in a month that is not the current one/month selected were faded a bit to draw attention to the days in the selected month. So in your screenshot it'd look like:
Nice work. Like I said in some past feedback, I think the ingredients are there for something solid, and to elaborate on that, it seems like the combination of allowing you to input the date in classic form widgets for accessible reasons and having the calendar for mouse users, this could work for us.
I think the specific implementation could be tweaked a little bit. What if instead of dropdowns, we had an input field where you could both type in
What if also, instead of those inputs being inside the popout, they were directly shown inline? Then the popout in its entirety could be aria-hidden.
Here are rough mockups:
Focus or click one of the fields to get the popout:
Don't pay too much attention to the specific visual styling of the input field, these would be normal input fields that would simply invoke the popout when focused.
We'd still have the same ingredients, just rearrange them a bit.
A sidenote I forgot to mention right above — my role in this is mainly as a designer, and the goal with the above mockups were to ensure accessibility, while ensuring the convenience of a date picker for mouse users. I will always defer to Tammie for final design thoughts on the overall picture, and I know she has many thoughts on date pickers. CC: @karmatosed
@jasmussen — this is the approach I took from the start. Unfortunatly, it would have required the following:
The popover managed to break the sidebar layout as well, so I decided to cut off the fat and concentrate on the actual matter.
So I decided to concentrate on tackling the keyboard navigation and accessibility issues first and foremost, without deviating too much from the current asthetics.
I am very happy to see the redesign mockup, but I suggest we create a new issue ticket called "Implement datepciker redesign" or something along those lines and I'll be happy work on it until @ehg tells me to stop.
Whilst I do think it's good to have a more accessible date picker in and thanks for all the great work here, if we also have a design let's do that at the same time. I would prefer we didn't have a half way state. Let's get the design work done by @jasmussen into this PR. I understand the urgency but there are some usability issues raised by such an intense UI that can be eased in the design.
I really like the work @jasmussen has done here and added a comment above to get that worked on as I think that's important. For input the date picker I am adoring right now is https://github.com/airbnb/react-dates:
What is being suggested I think is a solid design iteration, solid enough it should be done before we commit here.
@karmatosed Note that I have suggested initiating a new issue ticket to implement a redesign as has been discussed here, which is something I do support wholeheartedly as a longer–term vision.
Nevertheless, issue #1311 managed to have its first anniversary a little more than a week ago. Leaving it open and unresolved instead of implementing this PR, even if it is just a stop–gap fix is something that I feel disregards the needs of those who require the use of assistive technologies such as screen readers to use Gutenberg and Calypso.
Implementing said redesign (and the coordination work required) at a later date on one hand and the changes brought in with this PR on the other is not mutually exclusive, with the changes brought in here having the potential of being a step toward the redesign, and being very important in regards of accessibility.
I am looking forward to see @afercia's take on this ticket.
Thanks so much for your work, this is a powerful proof of concept, and as far as I'm concerned it has helped unlock a path forward both implementationwise and design wise.
We are in beta right now, barrelling towards feature complete. The ticket this means to solve is in the merge-proposal milestone, which means we won't ship a v1 without this addressed.
Although I could see an intermediate step, Tammie's comment also reminded me of past instances where we fix and issue partially and then immedately forget about the other aspects we promised ourselves that we'd come back to fix. As such, I can completely understand the desire to keep this one a bit longer in the oven, and I'd always defer to her on the larger vision.
Given all the work that's been done already, I can only imagine phase 2 of this PR will be much easier than phase 1 has been, due to all the hard work you've already put into it. If you are out of time to contribute that's completely and totally fine, we will be able to take the work you've done and address the phase 2 feedback. Thank you
Thank you for the PR, @aldavigdis!
I don't have any comment on the redesign question, I'll leave that to @karmatosed as the Gutenberg design lead.
I have some feedback on the functionality and implementation, however!
Why are there value checks in
Selecting an invalid date will cause the form value to jump around. Eg, if you select March 30, then change it to Feb 30 (say, if you wanted to change a scheduled post from sometime in March to sometime in Feb, and you decided to change the month first), the form value will automatically change to Feb 28. If you do it the other way, starting with Feb 28, then changing to Feb 30 (intending to change the month to March next), the form will auto-correct to March 02.
I like the idea of providing feedback on invalid dates, but it seems like it would be better to passively warn the person entering the date, rather than trying to correct whatever they've done wrong, before they've had a chance to correct it themselves.
When ordering the form elements, I highly recommend checking the behaviour of Core's touch_time() function. In particular, the
I'm a bit confused on why these totally unrelated E2E tests are failing: https://travis-ci.org/WordPress/gutenberg/jobs/440799548#L1441
I didn't touch editor alignment and they're failing for me locally too, even after rebasing onto the very latest master. Any ideas?
Oct 13, 2018
referenced this pull request
Oct 14, 2018
referenced this pull request
Oct 14, 2018
Oh, I tried to be clever in the branch and automate the
So I just left it alone and manually set the