Closed PhilipHoyt closed 9 years ago
@PhilipHoyt cool, we do agree! Would you like to help us out by sending PRs that fix some of those items? This would be much appreciated!
@pkozlowski-opensource hi, is this enhancement request still active / needed? I consider to try implement all suggestions given by @PhilipHoyt. Thanks
I think the request is still valid, though in the meantime I am not using the datepicker component.
Tthe datepicker has potential but is a bit obtuse which would be improved by doing something like separating the label "March 2015" from the action "view year", and by adding full accessibility.
I would be happy to provide design concepts and test the accessibility.
Thanks for your feedback. I definitely agree with the idea of separating button used to swap between day / month / year. Do you have some particular design ideas - any sketch, recommendation or something like that? I am relatively new in this usability area. So thanks for any kind of help. Is it a good idea to use any key shortcut to switch between day / month / year?
Above are two possible approaches.
I think the second option is straightforward and self-explanatory. Similar changes would have to be done to the "choose month" view to allow a person to access "choose year."
In the first one I removed the "week number" column to make it easier to move the arrows beside the date picker. I am exploring making a bigger change to the layout of the datepicker, hoping it will make the functionality self-explanatory without visible labels.
Since the enhancement here is described as "accessibility", I recommend adding hidden labels to any arrow buttons without text "next month", "previous month", "choose month".
iOS has similar functionality so it's worth having a look, here's a screenshot http://photos.appleinsider.com/13.06.17-Calendar-2.jpg
In iOS, moving between months or years is done by scrolling vertically, and they don't have a separate choose year view, probably because fast scrolling on the iOS touch screen makes it unnecessary.
I would prefer the second solution. Personally I think that removing week numbers is not I good idea. I have searched through the internet and I found this example of fully accessible date picker http://oaa-accessibility.org/example/15/. I like the idea of switching between main picker area / select prev month / select next month using TAB key. What's our opinion? I also studied some recommendations from that example. I think additional ARIA markup could be used. I would suggest to show whole date on the top of the datepicker widget and made date / month / year texts trigger selection dialog. This actions could be easily explorable by using aria-labelledby attribute (See: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute)
I am testing this using Mac accessibility tools on Chrome. I also have access to JAWS on windows, but I won't test using that today.
I do like being able to access the next month/previous month buttons using tab as in your oaa-accessibility example. I am not sure of the value of their advanced keyboard shortcuts since they aren't self-evident. I also like how you can move back a month by just hitting up arrow from the first week row, and forward a month using down arrow from the last week row.
One thing that is a problem, in my opinion, with both Angular and oaa-accessibility examples is that the labels on the day buttons as you move between them are never read by the screen reader. That may be a mac-only problem.
I agree with your suggestions to use ARIA markup, whole date using at the top.
Ok, thank you. Today I go abroad and I am 5 days without internet. When I come back I would like to start coding some prototype :).
@PhilipHoyt and @hack006 Check #3526 I just created. Any help and input are appreciated.
Closing in favor of #4772.
Angular-ui bootstrap datepicker has a lot of potential, given the keyboard accessibility. The following would make it fully accessible I think: