type: widget
release: 0.0
status: in development
demo/documentation: http://view.jqueryui.com/datepicker/demos/datepicker/
1 - Description:
This is a brand new planning page to discuss the code refactor of the current datepicker plugin:
http://jqueryui.com/demos/datepicker/
To have a fresh start on the planning on this refactor, the older wiki page that covered current and future datepicker and calendar ideas is archived here: DatePickerCalendar
The specific code and functionality changes we want to address in this refactor are:
-
Refactor the code to use the widget factory and follow the jQuery UI API
-
Use the new Globalize project for i18n and l10n: https://github.com/jquery/globalize
-
Improve datepicker positioning/z-index issues in dialogs and overlays, especially in IE
-
Add the ability to customize the buttons in the bottom button bar. This would allow users to add a "clear form" button, shortcuts like "today" or "next delivery date". This API should match dialog's button option.
Sampling of feature requests that we might want to consider adding or accommodating as an extension to core picker:
-
Show week numbers - worth including?
-
Select multiple days on a calendar
-
Select a range on a calendar
-
Disable or highlight/decorate list of specific dates or days of the week
- Add time selection.
- Handle all new HTML5 date and datetime types:
- date
- datetime
- month
- week
- time
- datetime-local
Existing Refactors
2 - Visual Design:
3 - Functional Specifications/Requirements:
Options:
- appendTo - DATEPICKER ONLY
-
disabled (inherited from widget factory)
-
dateFormat (String or Object, default: { date: "short" })
-
eachDay (function, default: $.noop)
-
hide (string, default: null) - DATEPICKER ONLY
-
max (date or string, default: null)
-
The maximum selectable date by the datepicker. Dates greater than max will not be enabled for selection.
-
For consistency with the native picker, do not change the input's value when this option changes - even if the value is now invalid. See http://bugs.jqueryui.com/ticket/9688.
-
Given string is parsed according to dateFormat option. Support for input attribute using format yyyy-MM-dd
-
min (date or string, default: null)
-
The minimum selectable date by the datepicker. Dates less than min will not be enabled for selection.
-
For consistency with the native picker, do not change the input's value when this option changes - even if the value is now invalid. See http://bugs.jqueryui.com/ticket/9688.
-
Given string is parsed according to dateFormat option. Support for input attribute using format yyyy-MM-dd
-
numberOfMonths (number, default: 1)
-
position (position options, default: { my: 'left top', at 'left bottom' }) - DATEPICKER ONLY
-
show (string, default: null) - DATEPICKER ONLY
-
showWeek (boolean, default: false)
-
value (date or string, default: null) - CALENDAR ONLY
-
buttons (object or array, default: null)
Methods:
- destroy (inherited from widget factory)
- disable (inherited from widget factory)
- enable (inherited from widget factory)
- option (inherited from widget factory)
- widget (inherited from widget factory)
- isValid - DATEPICKER ONLY
- Determine whether the datepicker's input contains a valid date (bounded by min and max and subject to dateFormat).
- close - DATEPICKER ONLY
- Programmatically close the datepicker. Use the open method to open it again.
- open - DATEPICKER ONLY
- Programmatically open the datepicker. Use the close method to close it again.
- refresh
- Updates the calendar widget and the input value.
- value
- Get or set the value as a string, bounded by min and max options.
- valueAsDate - DATEPICKER ONLY
- Get or set the value as a Date object, bounded by min and max options.
Events:
- close - DATEPICKER ONLY
- This event is triggered when the datepicker is closed
- beforeOpen - DATEPICKER ONLY
- This event is triggered before the datepicker is opened
- If canceled, the datepicker will not open
- open - DATEPICKER ONLY
- This event is triggered when the datepicker is opened
- select
- Triggered when a date is selected from the picker
- change
- Triggered when date has changed
Globalization:
4 - Markup & Style:
4.1 Initial markup examples
<input>
<input min="1970-01-01" max="2020-12-31" value="2009-05-22">
4.2 Recommended transformed HTML markup
(The HTML markup structure and classes that will be used by the scripts in the enhanced version)
4.3 Accessibility recommendation
(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices)
Issues with current datepicker:
- Lack of ARIA roles and properties to identify keyboard interaction and label controls
- Tab key is used to open and close the date picker
- use grid roles to override table markup semantics to identify the interactive behavior of the date picker
- improve labeling of dates in grid and calendar navigation controls
- Keyboard focus is indicated using color alone
- Manage keyboard focus based on user interaction, keep focus in a predictable and useful place in the calendar grid
- the next/prev month icons are invisble in high contrast mode, not indication of focused day is available.
- the controls/links in the date picker do not recieve programmtaic focus.
- Expansions for day abbreviations not provided
- (1194.21.a) Keyboard navigation and selection not fully supported in popup version.
- (1194.22.g, 1194.22.h) Row and column headers (Its not clear to me whether this makes sense for the datepicker since its not really a data table).
See example:
http://oaa-accessibility.org/example/15/
Reason for separating templates: Refreshing the entire datepicker during interaction confuses screen readers, specifically because the date picker title is marked up as a live region and will often not be announced if it's destroyed and recreated (as opposed to having its text contents change). Additionally, with a single template approach, clicking the "prev" and "next" links would lead to the entire template to being refreshed. The would cause a loss of focus because the focused link itself would be removed as well. Separating the templates gets rid of these accessibility issues, and also allows developers to modify parts of the datepicker without having to duplicate the entire template.
Proposed Keyboard Support (Default Date Picker)
Feature
|
Keyboard
|
|
---|
Open Date Picker |
- Tab into date textbox automatically opens and moves focus to Date Picker Dialog box
- Focus should be on the current date gridcell in the calendar grid after the dialog box opens; or If a date had already been entered in the textbox focus should be in the date gridcell identified in the texbox
|
|
Close Date Picker and no change to textbox |
- ESCape closes Date Picker Dialog box and moves focus to text box with no change to the date in the textbox
- Enter key on the Close Button closes Date Picker Dialog box and moves focus to text box with no change to the date in the textbox
|
|
Close Date Picker and update date in textbox |
- Enter key when focus is on a date gridcell in the calendard grid closes Date Picker Dialog box and moves focus to text box with the last selected date from the calendar grid populating the textbox
|
|
Navigate dates (Calendar Grid) |
- up, down, left and right keys move focus and selected date between gridcells in the calendar grid
|
|
Tab Navigation |
- Keyboard focus stays in date picker dialog box until dialog box closes
- Tab moves between:
- Close button
- Month navigation buttons (next month, previous month)
- Calendar grid
|
|
Other Features
Feature
|
Description
|
---|
entering date in textbox |
- Allow other formats (e.g. Jan, mm-dd-yyy...) and auto correct
- If only one format provide help information on the date format allowed (MM/DD/YYYY)
- Use aria-describedby to reference the formatting information
|
close button??? |
- Should date picker have a close button???
|
Labeling date cells |
- Use aria-label or aria-labelledby on each gridcell to create an accessible name for each grid cell options:
- "Day-of-week the day" (e.g Saturday the 10th)
- "Day Day-of Week" (e.g. 10th Saturday)
- aria-describedby to date and year information
|
Changes in month/Year |
- Live region to announce changes in month and year
|
Keyboard Testing:
W3C
Keyboard navigation on days that are not included the currently displayed month should move to the month automatically and lead to the day in the next or previous month.
- Tab -
-
Like other widgets, the date picker widget receives focus by tabbing into it. Once focus is received,focus is repositioned on today's date in a grid of days and weeks. A second tab will take the user out of the date picker widget. Focus initially is placed on today's date.
- User can tab to date input field to trigger the datepicker. Another [TAB] closes the datepicker.
- There is only visual focus on the date indicated by a pale yellow background.
- Shift+Tab -
- reverses the direction of the tab order. Once in the widget, a Shift+Tab will take the user to the previous focusable element in the tab order. (See above)
- Up Arrow and Down Arrow -
- goes to the same day of the week in the previous or next week respectively. If the user advances past the end of the month they continue into the next or previous month as appropriate. Only [CTRL] + [Arrow Key] will allow user to navigate the calendar.
- Left Arrow and Right Arrow -
- advances one day to the next, also in a continuum. Visually focus is moved from day to day and wraps from row to row in a grid of days and weeks.
- Shift+Control+Page Up - Moves to the same date in the previous year.
- Shift+Control+Page Down - Moves to the same date in the next year.
- Singleton Mode: acts as a toggle either selecting or deselecting the date.
- Contiguous Mode: Similar to selecting a range of text. Space selects the first date.
- Home - Moves to the first day of the current month.
- End - Moves to the last day of the current month.
- Page Up - Moves to the same date in the previous month.
- Page Down - Moves to the same date in the next month.
- Enter -
- If the calendar is a popup attached to some other widget (e.g., a text field), then Enter dismisses the popup, and the selected date(s) are shown in the associated widget.
- If the calendar is a static region on the page, then Enter confirms the selected date(s).
- Escape - in the case of a popup date picker, closes the widget without any action.
Color Contrast
- Need to change the styling of the element with role=gridcell with focus changing more than just background color
- Border style
- Border thickness
- Bold text date in cell
ARIA Support
- aria-activedescendant is being use to manage keyboard element being communicated as having focus to users of assistive technology
- Need to add aria-label or aria-labelledby attribute to each element with "role=gridcell" to provide "labels" to assistive technology
- Label should read "day of week" + "date" for example "Monday the 11th"
- Add aria-describedby attribute to each element with "role=gridcell" the div with the Year/Month information (e.g. div#ui-id-1-month-label)
- The button element inside the element with role="gridcell" should have "aria-hidden=true" attribute since it is not focusable and is read by some screen readers as "contains interactive elements"
- Don NOT use "aria-hidden" on elements with "role=gridcell", it hides the grid from ATs
- To have the change in Month/Year spoken automatically to screen reader users, add "role=alert" to the div containing the month year information e.g. div#ui-id-1-month-label)
4.4 CSS & Theme
(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.)
5 - Latest version of plugin:
http://view.jqueryui.com/datepicker/demos/datepicker/default.html
6 - Open issues being discussed
Options and methods which needs discussion
- defaultDate
- multiple calendar related
- stepMonths
- showCurrentAtPos
Here's all the current options and methods.
Options:
- altField
- The new datepicker has a select event, so this is trivial functionality to add on yourself.
- remove
- altFormat
- appendText
- Trivial to add on.
- remove
- autoSize
- This automatically sizes the input to accommodate the selected date based on its format. I'm at a loss for why you would need to do this.
- remove (show how to replicate?)
- beforeShow
- Using the widget factory makes this mechanism obsolete and it would be tricky to preserve this functionality.
- remove
- beforeShowDay
- Currently the "eachDay" option provides comparable features, with a saner usage. Need to review that.
- remove (show to to replicate with "eachDay")
- buttonImage
- remove (show how to replicate)
- buttonImageOnly
- remove (show how to replicate)
- buttonText
- remove (show how to replicate)
- calculateWeek
- Should be done in Globalize (create a test)
- remove
- changeMonth
- Add a demo or create an extension for calendar
- remove
- changeYear
- Add a demo or create an extension for calendar
- remove
- closeText
- No buttons built into the datepicker.
- remove
- constrainInput
- Suppressing user input is a UX bad practice. I don't believe we should provide this functionality.
- remove
- currentText
- No buttons built into the datepicker.
- remove
- dateFormat
- dayNames
- dayNamesMin
- dayNamesShort
- remove (show how to replicate with Globalize - see comments on this page)
- defaultDate
- duration
- This functionality will be handled by the new show and hide options
- remove
- firstDay
- Use Globalize instead
- Remove
- gotoCurrent
- No buttons built into the datepicker.
- remove
- hideIfNoPrevNext
- Trivial to hide links at the desired time with CSS.
- remove (show how to replicate with CSS)
- isRTL
- This is functionality we'll want and a sane API.
- Does Globalize provide the needed functionality?
- Check if the current implementation is correct
- preserve?
- maxDate
- Keep, but rename to "max"
- preserve
- minDate
- Keep, but rename to "min"
- preserve
- monthNames
- monthNamesShort
- remove (show how to replicate with Globalize - see comments on this page)
- navigationAsDateFormat
- Not sure anybody uses this but I could see how it might be useful.
- remove (ensure this can be preserved via an extension point (_buildPrevButton() / _buildNextButton() )
- nextText
- We should preserve this, just like dialog's closeText option.
- preserve
- numberOfMonths
- Exists in the rewrite, the multi-month support is not working properly yet.
- Question: Do we continue to support the array form of this option? See http://jsfiddle.net/tj_vantoll/GmyXj/. Seems like something we should probably do but it's not accounted for in the rewrite for now.
- preserve?
- onChangeMonthYear
- What is the use case?
- remove (show how to use changeYear extension)
- onClose
- Replaced by close event
- remove (show how to replicate with close event)
- onSelect
- Replaced by select event
- remove (show how to replicate with select event)
- prevText
- We should preserve this, just like dialog's closeText option.
- preserve
- selectOtherMonths
- Covered by the "eachDay" option
- Create helper methods ($.ui.datepicker.xzy) to set eachDay option (if requested by users)
- Same for noWeekends
- remove (show how to replicate)
- shortYearCutoff
- Check if this is handled by Globalize
- What does moment.js do?
- remove
- showAnim
- Replaced by the show option.
- remove (show how to replicate with the show option)
- showButtonPanel
- Replaced by the buttons option.
- remove
- showCurrentAtPos
- I've always found the name of this option confusing but this is functionality I think we need to preserve.
- preserve?
- showMonthAfterYear
- This should be handled by Globalize.
- remove
- showOn
- Trivial to add on this functionality.
- remove (show how to replicate)
- showOptions
- Replaced by show option
- remove (show how to replicate)
- showOtherMonths
- Covered by the "eachDay" option
- Perhaps we want to create a helper method for this (see selectOtherMonths option)
- remove
- showWeek
- Implemented in the rewrite, seems fine to keep it
- preserve
- stepMonths
- Seems reasonable, but under discussion
- preserve?
- weekHeader
- If showWeek remains, this needs to stay, but perhaps be renamed
- remove?
- yearRange
- Use changeYear demo / extension
- remove
- yearSuffix
- This should be handled by Globalize.
- remove
Methods:
- destroy()
- dialog()
- getDate()
- Use valueAsDate method
- remove
- hide()
- isDisabled()
- Replaced by disabled option
- remove
- option()
- refresh()
- Seems like this would be inconsistent with our current refresh methods. Also I'm not sure what the use case even is for this.
- remove?
- setDate()
- Replaced by the value() method
- remove
- show()
- widget()
Next Steps / ToDo (Felix)
- a11y functionality
- figure out how to handle multiple month
- differences between datepicker and calendar widget
- RTL / bidi support
- There is some existing CSS
- In master, this controls arrow keys, prev/next icons, and corner radius on headers in multi-month
- Can this be determined from the locale instead of exposing an option?
- Infos from PR #1341
- Fix RTL LTR direction (available at cldr.main("layout/orientation/characterOrder"), values are left-to-right or right-to-left)
- RTL in master is just flat out wrong with changing DOM positions. Just let the browser do the right thing.
- Non-code related
- Start creating an upgrade guide
- Create getter / setter methods for this.gridId and this.viewDate as extension point
- Tests
- Add tests for Globalize based upon old code base (see comment and code)
- Add assertion that verifies where the focus should be (see comment)
- Use multiple timezones when running tests on travis (see comment)
- Handle timezone issues (extract Date creation, calculate offset, see comment)
- Add calendar and datepicker to the requirejs task in the Gruntfile
- Demos
- Re-order demo lists in index.html files (link to comment)
- dropdown-month-year: Broken (as not implemented)
- Implement this as a demo or an extension WIP
- icon-trigger: has open tasks
- keep this demo until we work on the migration guide for the new API, where we include this example, then delete the demo as it's promoting bad practice
- Visual tests
- Datepicker in Dialog has stacking issues
Proposed functionality of the value method / option
value method:
- get or set the currently selected value as a string
- string must be formatted as defined in option.dateFormat
- setter changes input value if valid string was passed (bounded by min and max options)
- getter returns
- the formatted current input as a string if valid (valid date string and min / max option)
- the current input value as a string if able to parse (valid date string)
- null if not able to parse
value option / valueAsDate method:
- get or set the currently selected value as a Date object
- setter changes input value if valid date object was passed (bounded by min and max options)
- getter returns
- the formatted current input as a date object if valid (valid date object and min / max option)
- the current input value as a date object if valid (valid date object)
- null if not a valid date object
Split Datepicker Widget in Datepicker and Calendar Widget
Calendar Widget
- basic functionality for displaying a calendar UI
- specs probably as listed in section 1 but without pop-up related methods and events (appendTo, hide, show, position, open, close, ...)
- has value option and methods
Datepicker Widget
- input based as the current, stable Datepicker Widget
- uses a internal reference of the Calendar Widget
- specs as listed in section 1
- has no value option because it's based upon a native input
- has value and valueAsDate methods
- remove inline functionality (use Calendar widget instead)
See PR: https://github.com/jquery/jquery-ui/pull/1260
external/date.js
Currently, `date.js` is located under `/external`. But, it is NOT an external library. It's NOT hosted (neither version-controlled) anywhere except in here. Aside from confusing, this makes AMD or CommonJS setup hard/awkward. So, we need to either make it an external library or move it into `./ui` (where all our sources files live).
Globalize related
Currently, `external/localization.js` holds CLDR data. We need to figure out how to deal with this data in demos and tests.
The translation data ("done", "prev", "next"; button names basically) is configured via the labels option.
Week numbers are currently implemented. Should they be removed and just shown in a demo with an extension?
Change eachDay to provide an actual element and simplify the custom API. Idea (not full implementation): https://gist.github.com/scottgonzalez/fadc55ffadff5241ffb1
When parsing min and max attributes, require them to follow the HTML spec. Same should be applied to spinner (though that is a breaking change)
Do we want to support an array for numberOfMonths?
Do we need a refresh() method? When would it be used?
What is the use case for the beforeOpen event?
Need to add a culture/locale option to match spinner or decide to remove it from spinner. -> Option has been added to datepicker.
Does this handle non-Gregorian calendars?
Handle year before month in header based on locale.
Compared to master, the default date format is different, is that intended? Master has 4 digit years, rewrite only 2
Comments (39)
Scott González said
at 4:55 pm on Jun 15, 2011
It should be possible to render a Broadcast Calendar with the rewrite. See http://bugs.jqueryui.com/ticket/7479
Scott González said
at 7:10 am on May 25, 2012
Accessibility notes: http://bugs.jqueryui.com/ticket/7863
Scott González said
at 3:45 pm on Mar 25, 2013
https://github.com/xsoh/Hijri.js might be a useful reference for the non-Gregorian calendar support.
Scott González said
at 7:36 am on May 13, 2013
http://www.fourmilab.ch/documents/calendar/ from https://github.com/jquery/jquery-ui/pull/986
juan.lanus said
at 4:45 pm on Jun 18, 2013
In order to be operable with the keyboard, it should open with Alt+Down, like a dropdown.
Then it should accept keyboard input.
Jon Gunderson said
at 8:14 am on Sep 3, 2015
I talked about this issue with the W3C ARIA Authoring Practices guide group and they are recommending to primarily support down arrow with no modifiers and optionally supporting alt+Down arrow for opening the Datepicker dialog box and moving focus into the dialog box.
juan.lanus said
at 4:51 pm on Aug 30, 2013
There is this ongoing thread in UX.stackoverflow (the usability site)
"In a calendar, should we show dates that fall outside the current month?"
http://ux.stackexchange.com/questions/44059/in-a-calendar-should-we-show-dates-that-fall-outside-the-current-month
The answer being developed tends to be a yes. So IMO this should be an option.
juan.lanus said
at 11:12 am on Aug 31, 2013
Some usability comments on the UI design:
1- Too many borders.
Day cells should either have have collapsed borders or no borders at all (and thus might get round corners like everybody else). The rationale is that all those tiny lines have to be processed by the brain's CPU in the (very fast) process of building the UI mental map and it would be a bit easier with less lines. It's 31 x 4 additional elements to process and discard. This is why we render <table>s with border-collapse almost w/o exceptions.
2- Too mean weekday names. This UI is not about "Su Mo Tu ..." but it looks like it was, because those are the most prominent items at first sight. Look at "April 2009": it's there when you want to see it, but it's not yelling at you.
The row should have a smaller height, and the day names should be deemed, like in gray (but let a designer decide).
3- Day number fall shy: too small, too deem.
This UI *is* about them, so let's show them proudly, mainly using a bigger font-size albeit without enlarging the line-height. Also, they will be easier to grok at the first glance if they were set a bit farther from the right bound (but not centered, please!). The size thing will also be excellent for elder people with old eyes.
Also rendering the day numbers in a color other than (almost) black introduces another font for the brain CPU to process. This is the reason why pages rendered using many different fonts (or font variants) never look "classy".
Jon Gunderson said
at 1:40 pm on Dec 7, 2015
Keyboard focus styling needs to change more than background color to meet W3C WCAG 2.0 requirements. Should I open a bug on this issue?
fnagel said
at 2:33 pm on Dec 7, 2015
Is this comment about the current Datepicker or the upcoming rewrite?
I guess for the "old" one as the rewrite has ARIA attributes: Please open a a ticket in our bug tracker.
Scott González said
at 2:44 pm on Dec 7, 2015
Can you explain what else would need to happen or link to the relevant requirements? http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/C15 seems to say that changing just the background color or just the border is sufficient.
In either case, this would not be a bug filed against the datepicker component, as individual widgets never deal with this type of styling. That's a theme-wide configuration. So we may need to change the default theme, which would be filed against the CSS framework.
Jon Gunderson said
at 1:57 pm on Dec 16, 2015
Is there a default theme that could support the focuse and color contrast requirements for WCAG 2.0?
Who owns the default theme?
Scott González said
at 4:40 pm on Dec 16, 2015
We own all of the themes. There are no separate teams within jQuery UI.
However, any changes to state styling affect everything, not just datepicker. We can make whatever changes are necessary, but I still want to see references to requirements that we're not meeting.
Jon Gunderson said
at 5:05 pm on Dec 16, 2015
Scott,
These are the major WCAG 2.0 requirements related to focus.
SC 1.4.1 Use of Color
http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color
SC 2.4.7 Focus Visible
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visible
There is CSS Pseudo elements :focus, but some time you need to add a focus class on a container like for radio buttons and checkboxes,
Richard Oakham said
at 10:00 pm on Jan 21, 2016
Proposal for added function: Ability to choose what month the month/year selector boxes appear on, when using multiple months (and in particular when showCurrentAtPos is non-zero, but not limited to that case)
Rationale: User confusion when the month that they select to display is not the month that appears below the selector boxes (leading to incorrect dates being selected due to the assumption from them that the month they chose is the one below the selectors) , and the selector boxes do not contain the month just selected on redraw, leading to user confusion.
Test implementation made with existing Datepicker that modified the setting of "secondary" in the call to the function that produced the top line (month/year), detecting when the row/col matched a new option showSelectorAtPos, rejected due to rewrite in progress (advised to post request here instead)
Many thanks
Richard Oakham said
at 10:39 pm on Jan 21, 2016
Looking at the new code I can't find the showCurrentAtPos functionality, nor where the selection of month/year by drop-down may be handled - happy to take a look on if the function above is possible, but wondering if the Preserve? above has turned into Remove (if so, a big loss of functionality for me).
fnagel said
at 11:48 am on Dec 25, 2016
We'll implement the dropdown-month-year example as an extension for calendar.
fnagel said
at 12:15 pm on Jun 7, 2017
http://view.jqueryui.com/datepicker/demos/calendar/dropdown-month-year.html
Jon Gunderson said
at 9:21 pm on Dec 11, 2016
Is there anyway to improve the default visual focus to be easier to see, for example to increase the width and contrast of the date or button with keyboard focus.
This is needed for people with low vision (e.g not blind) to see where visual focus is.
It will help all keyboard users in general see where the visual focus is too, making the keyboard option easier for everyone to use.
Jon Gunderson said
at 9:34 am on Dec 13, 2016
What are you trying to do with aria-hidden, I can help you understand better techniques to do what you are trying to do.
fnagel said
at 12:04 pm on Jan 29, 2017
Hey Jon!
aria-hidden attribute has been removed, see https://github.com/jquery/jquery-ui/pull/1788
You could test this using the latest datepicker branch: https://github.com/jquery/jquery-ui/tree/datepicker
Would you mind giving some more feedback how to handle the multiple month functionality[1] and differences between datepicker and calendar widget[2] in general?
Kind regards,
Felix
[1] http://view.jqueryui.com/datepicker/demos/calendar/multiple-months.html
[2] http://view.jqueryui.com/datepicker/demos/datepicker/default.html and http://view.jqueryui.com/datepicker/demos/calendar/default.html
Jon Gunderson said
at 8:14 pm on Feb 15, 2017
Felix,
Sorry for the delay in response.
I need to ask the ARIA authoring practices group about some of the uses of ARIA with grid content and keyboard focus management.
I would suggest some improved labeling:
1. For the next and previous month button, can you include what month you will be moving to instead of just "Next" and "Previous".
2. The labels for the gird cells could maybe spell out the month, for example: "Friday, 17 February 2017" instead of "Firday, 2/17/17"
I will have some more suggestion after the ARIA meeting on Monday.
Thank you for your continuted work on the JQuery-UI datepicker.
An accessible dtaepicker is a big issue for accessibility.
Jon
fnagel said
at 3:47 pm on Mar 8, 2017
Hey Jon,
any news on the feedback of the ARIA authoring practices group?
I was pretty busy the last couple of weeks, but should gather some free time to work on datepicker soon :-D
> An accessible dtaepicker is a big issue for accessibility.
I'm confident we'll create a solid solution together!
Regards
Felix
Jon Gunderson said
at 9:55 am on Apr 6, 2017
Can we set up a meeting to talk abut some of the recommendations, I think it would be easier to talk about these issues
Jon Gunderson said
at 1:46 pm on Mar 10, 2017
Sorry for the delay the group has not met for a few weeks due to presidents day in USA and CSUN conference in San Diego.
I will try to get some feedback on Monday's meeting.
Apparently Matt King is working on an example and I would like to get the complete design pattern he is using so I can compare it to what you are doing.
Hope this works out for your schedule.
Jon Gunderson said
at 9:55 am on Apr 6, 2017
Here are some changes for the accessibility:
* Use live region for the month
* Use column headers (e.g. role=coumnlheader)
https://www.w3.org/TR/wai-aria-1.1/#columnheader
* Button should be getting keyboard focus in grid (e.g. then remove aria-labeling on GRIDCELL)
* Use aria-selected on gridcell
* Opening the date picker
* Currently opens automatically, need to look at how keyboard focus is managed between textbox and date grid
It might be good to setup a meeting to discuss the details of recommendations.
fnagel said
at 1:57 pm on Apr 12, 2017
Hey Jon,
thanks for the update and the feedback! Are you able to update the wiki specs according to your proposed changes?
Would be easier to have a more in depth description of what you have in mind.
I agree a meeting would be helpful. Sadly I'm about to move in a new flat and have very little time at the moment.
It would be a shame to wait until I have more spare time so Scott will figure out something in order to setup a meeting.
I will try to join the meeting if it'S possible somehow.
Thanks in advance and kind regards
Felix
Jon Gunderson said
at 12:16 pm on Apr 14, 2017
I will try to create an example of the markup and send to you by next week.
Jon Gunderson said
at 1:53 pm on Apr 17, 2017
Here is a link to more detailed comments and some sample code for use of aria for the datepicker:
Comments:
https://github.com/jongund/jquery-ui-datepicker
Sample Grid Code for using ARIA (many changes, but much simpler use of ARIA)
https://github.com/jongund/jquery-ui-datepicker/blob/master/aria-markup-example.html
Let me know if you have any questions or want to talk,
Jon
fnagel said
at 8:13 am on Aug 26, 2017
Finally found some time to implement your feedback. Feel give some feedback: https://github.com/jquery/jquery-ui/pull/1829
Benjamin said
at 3:04 pm on Jun 5, 2017
What happens to value and period pairs (for example "+1m +7d") now that we are using Globalize?
If we plan to keep value and period pairs I would appreciate it if the parsing logic would be made a public API that I can use in Month Picker.
Right now I have quick and dirty proprietary implementation that I would be glad to get rid of.
Scott González said
at 11:29 am on Jun 6, 2017
That's a good question. I'm not sure if Globalize plans to implement that type of logic, hopefully Rafael can chime in and let us know. If Globalize doesn't support it, we may end up dropping it and requiring that logic to live in the app code. If Globalize doesn't support it, and we do decide to implement it, it would be part of a date library, not built directly into the datepicker, so the API would definitely be public.
Benjamin said
at 3:23 pm on Jun 5, 2017
I noticed it says all off the button options are being removed and it says "show how to replicate".
How are we planning to allow the user to replicate this functionality?
Scott González said
at 11:37 am on Jun 6, 2017
There are two types of buttons being removed. One is the button used to display the datepicker (when not using focus on the input). That would be replicated by using the calendar widget instead of the datepicker widget and then displaying the calendar when your own custom button is pressed. The calendar would then be hidden upon a selection or a click outside. The total lines of code to implement that would be pretty small. An extension could easily be built to standardize the way that's done, but there are just too many options for the button itself, which makes the API a bit bloated. The second type of buttons that are being removed are the buttons in the footer of the datepicker. There won't be any built-in buttons, but you'll have the ability to create any buttons you want, just like you can with a dialog. Extensions for popular buttons would be pretty easy to implement as well.
Benjamin said
at 3:35 pm on Jun 6, 2017
Assuming I understand correctly the user will create a button and bind a click handler which will create a calendar and position it under the textfield.
However it's not clear to me what element are you supposed to instantiate the calendar widget on (textfield, button, document body, blank div, etc...)
I also don't understand how are you going to keep this simple assuming:
1. The user is now responsible for binding document click (and other element event) handlers for closing the calendar.
2. The user is now responsible for preventing the calendar from closing when the user clicks the button/textfield (because they are considered outside the calendar).
3. It can be challenging to ensure that the button is consistent with the Datepicker's disabled/enabled state.
Feel free to take a look at how we overcame these challenges in the Month Picker project:
https://github.com/KidSysco/jquery-ui-month-picker/wiki/Button-Option
fnagel said
at 11:06 am on Jun 7, 2017
Here are some demo links (using latest datepicker branch) which should help to understand what is possible for now:
http://view.jqueryui.com/datepicker/demos/datepicker/icon-trigger.html
http://view.jqueryui.com/datepicker/demos/calendar/buttonbar.html
http://view.jqueryui.com/datepicker/demos/calendar/dropdown-month-year.html
Please take a look in the source of each html file!
Benjamin said
at 12:46 pm on Jun 7, 2017
As discussed in todays meeting we want to make it easy for the user to customize the button (regardless of localization).
We decided it's worth adding a button option which is similar the Month Picker's button option:
https://github.com/KidSysco/jquery-ui-month-picker/wiki/Button-Option
This removes the need to:
1. Maintain state variables to prevent the input field from opening (this can get messy when you have multiple instances on date picker with button on the page).
2. Keep the button's disabled state consistent with the data picker's disables state.
3. Bind event listeners to the button.
The button option will accept:
1. Any valid input for the jQuery constructor (e.g. selector, string of html, DOM element, instance of jQuery).
2. function(options) { return options.disabled ? 'Any valid input for jQuery constructor' : $(...); }.
Benjamin said
at 4:58 pm on Jun 7, 2017
Can I give implementing the button option (and opening a PR against the datepicker branch) a shot?
Scott González said
at 5:20 pm on Jun 7, 2017
Absolutely!
You don't have permission to comment on this page.