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

Develop example of date picker design pattern using a combobox that opens a dialog #34

Closed
ckundo opened this issue Apr 30, 2016 · 27 comments
Assignees
Labels
Example Page Related to a page containing an example implementation of a pattern
Milestone

Comments

@ckundo
Copy link
Contributor

ckundo commented Apr 30, 2016

Add a mobile-compatible example of a date picker that employs the form of the ARIA 1.1 combobox pattern that pops up a dialog.

Completing this issue will also complete issue #534.

Development is in the issue34-date-picker-examples branch. Use that branch as the base for pull requests related to this issue.

Preview link for feature branch

Date picker combobox example in feature branch

Related to issue #57.

@ckundo
Copy link
Contributor Author

ckundo commented Apr 30, 2016

I'm taking a pass at this now.

@ckundo
Copy link
Contributor Author

ckundo commented Apr 30, 2016

FWIW, there's a solid example of this marked up already at http://www.oaa-accessibility.org/example/15/. Is it worth reaching out to the author to reuse their example here?

@ZoeBijl ZoeBijl added the Example Page Related to a page containing an example implementation of a pattern label May 1, 2016
@jnurthen
Copy link
Member

jnurthen commented May 6, 2016

@jongund @a11ydoer is the code at http://www.oaa-accessibility.org/example/15/ either of yours?

@mcking65 mcking65 added this to the 1.1 APG Release 2 milestone Aug 15, 2016
@mcking65 mcking65 changed the title Add Date Picker code example Develop example of Date Picker design pattern Aug 15, 2016
mcking65 pushed a commit that referenced this issue Dec 4, 2018
For issue #34, add a directory for datepicker examples and a first cut of code.
@mcking65
Copy link
Contributor

mcking65 commented Dec 4, 2018

Here is the initial cut of an example page by @jongund merged into the issue34-date-picker-examples branch with commit 5d16101.

Rather than immediately tackling issue #57, this example could work as an example for the combobox pattern. That pattern needs an example of a combobox that pops up a dialog.

@jongund
Copy link
Contributor

jongund commented Dec 14, 2018

@mcking65 I have pushed a new version of the datepicker example. I had to rewrite most of the code, but it should be much easier to make modifications to the example with the new code base.

@jongund
Copy link
Contributor

jongund commented Dec 14, 2018

@mcking65 mcking65 changed the title Develop example of Date Picker design pattern Develop example of date picker design pattern using a combobox that opens a dialog Feb 4, 2019
@mcking65
Copy link
Contributor

mcking65 commented Feb 4, 2019

Per discussion in today's meeting, issues that need further discussion:

  1. Where should focus go after a date is chosen from the grid in the dialog? If it goes to the text field, that pops open mobile keyboards. If it goes to the down arrow icon, it is confusing for screen reader and keyboard users who moved focus into the dialog from the text field with down arrow.

  2. When should the dialog be visually displayed? It is very common for calendars to display when the text field is focused or clicked. Does that mean the user has to move focus out of the input to get the calendar to disappear?

@accdc
Copy link

accdc commented Feb 7, 2019

Hi,
I've been running some experiments, and have created two Auto onFocus ARIA-based date pickers for you to try out using the keyboard and with screen readers.

  1. Editable standard input field and no date restrictions.
    http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20Auto%20Open)/demo.htm

  2. Readonly standard input field with relative forward and backward disabled dates plus disabled weekends.
    http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20ReadOnly%20Auto%20Open%20plus%20Disabled%20Ranges)/demo.htm

Directions:

  1. Set focus to the input field, the date picker opens automatically.
  2. Desktop keyboard users can press the Down arrow to move focus into the calendar to move around as desired, or press Escape to close the calendar before or after moving focus into it.
  3. Touch device users can tap the associated toggle button to open or close the calendar as desired.
  4. After a date is saved, focus is always set back to the input field.

Personally, I think the keyboard functionality and screen reader feedback is very helpful, and this design pattern is already accessible in JAWS12 through 2019 and in NVDA using IE11, Firefox, and Chrome Canary.
I also just tested this in iOS Safari with VoiceOver, and it works as expected there with no accessibility issues that I can detect, even when focus is returned to the input field.

Some notes, this is not implemented as a combobox because for this, it doesn't need to be. Also, within this design pattern, you will notice that the external toggle button is also in the tab order. Though it can be taken out using tabindex="-1", I don't recommend this as a practice, because there is no guarantee that sighted keyboard only users will always be aware that they can press the Down arrow on the input field to move focus into the date picker, and having an explicit button for this purpose guarantees accessibility for all user types regardless.

The code for these widgets can be found within the Coding Arena in the download at
https://github.com/whatsock/tsg

Best wishes,
Bryan

@a11ydoer a11ydoer pinned this issue Feb 7, 2019
@a11ydoer a11ydoer unpinned this issue Feb 7, 2019
@accdc
Copy link

accdc commented Feb 8, 2019

As a quick update, others at Level Access have been testing the same design pattern I shared here, and behaviorally it does appear to be a reliable one. There were only a few issues with unreliable user expectations, where it wasn't clear that pressing the Down arrow was the expected keystroke for moving focus into the calendar. As a general paradigm however, and with proper visual indicators such as an arrow icon and the like for making it clear when the input field has focus that pressing 'down' is an option, most of this can be addressed by general public exposure and basic training for using these types of widgets, as long as we can establish a general keyboard pattern that we agree upon and publicize clearly.

A quick note regarding the examples I recently posted: At present I have these set not to show onFocus when a touch device is detected, because I’m not sure how disruptive that would be for mobile device users, which unfortunately includes all desktops with touch-support monitors like hybrid laptops. I haven’t found a simple way of differentiating these reliably as yet.

This is something we are going to have to keep in mind for all of our widgets though, because the keyboard paradigm does not always port equally over into touch, especially when some devices do both such as hybrid laptops. This is another reason why it is important to ensure that the extra triggering element remains in the tab order, to account for those who cannot access the standard event trigger when this is focus-based.

@mcking65
Copy link
Contributor

@jongund, here is a summary of today's discussion ...

Where should focus go after a date is chosen from the grid in the dialog?

It should return to the edit field and close the dialog. For most devices and assistive tech, this is the best experience. One compromise is that this does have the downside that it may re-display a touch keyboard.

  1. When should the dialog be visually displayed? It is very common for calendars to display when the text field is focused or clicked. Does that mean the user has to move focus out of the input to get the calendar to disappear?

Display the dialog when:

  1. The text field receives keyboard focus.
  2. The text field or down icon is touched. Note, however, if the text field is touched when the dialog is not open, only open the dialog, DO NOT focus the text field. If the text field is touched when the dialog is open, focus the text field. This should prevent unwanted display of the keyboard.
  3. The text field or down icon is clicked with a mouse. Clicking the text field should, as is normally expected, focus the text field.

Close the dialog when:

  1. Escape is pressed and focus is either in the dialog or in the text field.
  2. Focus is in the text field and tab or shift+tab is pressed.
  3. The dialog cancel button is clicked or touched.
  4. The dialog is open and the down arrow icon is clicked or touched.

Move keyboard focus into the dialog when:

  1. Focus is in the text field and up or down arrow is pressed.
  2. The user clicks or touches in the dialog.

@mcking65
Copy link
Contributor

Is it possible we could prevent unwanted display of the touch keyboard when a date is chosen by detecting when a date is chosen by touch? That is, if a date is touched and the dialog is closed, place focus on the down arrow icon. However, if a date is chosen via the keyboard or mouse click, put focus in the text field.

If we did this, we would want the accessible description of the down arrow icon to reference the text field. I am assuming the accessible name would be "Open calendar."

@accdc
Copy link

accdc commented Feb 12, 2019

Hi,
Based on our discussion yesterday, I've made several important changes to the ARIA date pickers I've referenced for testing. This will probably help as we try to document a reliable keyboard paradigm for both combobox and non-combobox patterns, as well as to address hybrid patterns that work equally well across both keyboard and touch devices, so please test these using both device types.

James, I tried to locate the test urls you sent me, but I couldn't access this in my IRC history and it doesn't appear to be in the meeting minutes. Either way though, I understand your points about having a need to display the date picker on touch without showing the virtual keyboard, and I have already solved this without requiring focus redirection to do so.

A few notes about the changes.

  1. I have made it possible to auto-render the calendar on touch screen devices, which includes hybrid laptops, and mobile devices like iPads and iPhones. This includes relevant state indicators such as aria-expanded where relevant to convey this to screen reader users. For editable date picker input fields, you can touch the input to render the calendar, yet this will not render the virtual keyboard, but if you touch the field again, it will render the virtual keyboard and make the calendar disappear. This works with VoiceOver running by double-tapping the input field as well.
  2. For sighted keyboard only users, I have added a visual indicator to convey that the ‘down’ arrow key is active when the calendar is rendered, which disappears when the calendar is closed, to make it clear that you can press the Down arrow to navigate into the date picker after focus is set to the input field.
  3. I have updated the instructions at the end of the page to match the page functionality so as not to confuse everybody going forward.

Test urls

  1. Editable
    http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20Auto%20Open)/demo.htm
  2. Readonly
    http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20ReadOnly%20Auto%20Open%20plus%20Disabled%20Ranges)/demo.htm

Explanation

As a general design pattern, we should not rely upon focus movement hacks to either display or not display specific platform features like virtual keyboards. Instead, we should keep focus in a predictable and accessibility approved location and update functionality accordingly using the attached events for whatever widget currently has focus. This can be done by modifying the event order of precedence when triggered on the input field, and it does not require setting focus to inactive parent elements to trick the browser into doing something different.

The above examples show the results of this methodology, and the only technique that is being used is the utilization and conditional processing of specific attached events on the input field. Specifically, these include the ontouchstart and onfocus event handlers. The ontouchstart handler is always processed before the display of a virtual keyboard, and if returned false (event.preventDefault) is used to cancel this handler, then it will not display the virtual keyboard on the screen, and this event will only fire when the input field is touched using a touch screen. If ontouchstart is canceled, then the onFocus event will not fire either.

So, to achieve the same logic on an auto-opening calendar when focus is set to an editable input field, do the following.

  1. Attach both an ontouchstart and onfocus handler to the input.
  2. Within the ontouchstart handler, check if the calendar is already open, and if so, do nothing. Otherwise, render the calendar and return false to prevent further processing. The ontouchstart handler will only fire when touched.
  3. Within the onfocus handler, check if the calendar is already open, and do nothing if so. Otherwise, render the calendar and provide a help prompt such as a live region to convey to non-sighted screen reader users that the down arrow key is needed to move focus into the calendar. The onfocus handler will fire when keyboard users set focus to the input, and also after ontouchstart fires if ontouchstart is not cancelled beforehand. The touch event can be queried to ensure that keyboard specific instructions are only announced for keyboard users.
  4. Add an onclick to the input field, and within that handler, check if the calendar is already open, and close it if so, which will turn the input field into a toggle and allow for the display of the virtual keyboard when the editable input field is touched a second time using a touch device.

Every time a calendar is rendered, preferably within a callback for this purpose, aria-expanded needs to be set on the input field to convey the active state of this calendar for non-sighted screen reader users. Also, if a separate triggering element is present that can be used as a toggle like in the examples above, these too need to include aria-expanded to convey the same thing, since both control the same calendar, and the triggering element that has focus must convey its active state regardless which one it is.

I've also had these example design patterns extensively reviewed internally, and to ensure accessibility for sighted keyboard only users, it is necessary to include a dynamically updated visual indicator such as an arrow icon to convey that the user can press the Down arrow when the input has focus to then move focus into the calendar for navigation. Also, a clear visual indicator does not have to be normalized for different languages like a plain text message would have to be.

By combining all of these things as I did, you can indeed create a reliable and provably accessible auto-renderrable date picker that works across both desktop and touch devices equally within the same design pattern; without having to include focus movement hacks to disrupt native functionality within mobile devices.

To review the code for these widgets, it has already been added to
https://github.com/whatsock/tsg

@accdc
Copy link

accdc commented Feb 21, 2019

Hi,
A bit more feedback with continued testing internally for this widget type.

Apparently, for sighted keyboard only users, it can be confusing to only provide Down arrow access into the calendar, because this is not an expected widget type like a list or menu as dropdowns are styled as.

As such, the recommended fix is to provide Down arrow as the intended method for doing this, however pressing Tab will also set focus into the calendar when expanded, which allows all user types to most accessibly use this widget type with the least amount of confusion. Escape can still close the calendar as before to allow keyboard users to continue navigation as expected as well. Also, pressing Shift+Tab will automatically close the calendar when focus is still on the editable input field.

For testing, this functionality has been added to the live demo at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20Auto%20Open)/demo.htm

@pbossley
Copy link

Sorry if I missed this somewhere in the comments, but some programatically associated keyboard instructions for screen reader reliant users e.g. maybe with aria-describedby might help a lot in ensuring a minimum of problems for users encountering this for the first time.

@frastlin
Copy link

frastlin commented Feb 22, 2019

@accdc I like that example, but for some reason, when using NVDA and Firefox, I get the following behavior:

  1. When hitting down arrow in brows mode over the top of the text input, the calendar expands and when I hit enter on the dialogue, I am taken to a place with only the navigation buttons, not the dates.
  2. When I switch a month in the calendar view, the instruction text is read again. this is really annoying when quickly moving through dates.

I really like this functionality as a calendar though.

@pbossley yes,, there should be something similar to "pres down arrow to view calendar", but it is not a very big deal as long as there is a button in the next index that when clicked will open the calendar.

@accdc
Copy link

accdc commented Feb 22, 2019

Thanks @frastlin,
I see what you mean, for now I've disabled the auto-announcement of the help text every time a new month is rendered, and it will only announce the help text the first time the calendar is opened and focus is set within it.

I also reproduced the arrowing you mentioned in NVDA, and this is a combination of things, not so easily addressed for this type of auto-opening widget.

The way that the input field works, is by using an onFocus handler to auto render the date picker visually, and this is necessary for sighted keyboard only users.

However, NVDA, when arrowing down the page in Browse Mode, will automatically trigger the onFocus handler upon any element that has one attached, which is why the calendar is auto-opening when you read it without entering Applications Mode first as it does when you press Tab instead. So, this is why when you press Down again you arrow passed the edit field instead of opening the calendar as you would expect.

For this to work in NVDA, you would have to press Enter on the edit field first to enter Applications Mode before you use the Down arrow to set focus into the calendar.

Unfortunately there appears to be no way to prevent NVDA from doing this auto-onFocus triggering prematurely, which is another reason why it is important to make sure there is a second button-like triggering element that performs the same action next to the input field, so that non-standard keystrokes and unexpected circumstances like these can be circumvented by manually activating the associated toggle button instead.

@frastlin
Copy link

NVDA still says something about a new dialogue every month.
Maybe if the user focuses the button and the button is expanded, then it will collapse.
The dialogue puts you into the navigation area and it is not clear how to get into the calendar when you are in the navigation area. I would say if one is in the navigation area, and they press escape, it jumps them into the calendar, and if they are in the calendar, then escape closes the calendar.

@accdc
Copy link

accdc commented Feb 24, 2019

Hi @frastlin,

With some experimentation, I was able to track down an order of events that allows for NVDA to auto-close the calendar when arrowing. So, you can now arrow down the page using NVDA + Firefox in Browse Mode, and when you arrow past the edit field it will automatically close the calendar. This means, however, that you will have to manually activate the trigger button in order to open the calendar if you go past the focusable edit field.

Also, I changed which elements are exposed in the accessibility tree, and which ones have accessible names, so you should now find it much less verbose when switching between months. You will still hear the word 'dialog' however, but this is something that NVDA does automatically when focus is set within an ARIA dialog widget, and this is impossible to turn off. Even so though, you should find that the feedback is more understandable. I also disabled the announcement of table feedback which had to do with exposed element structures in the accessibility tree, since the column and row counts were not actually helpful in any way when announced as part of this navigation.

Relevant test pages:
Editable: http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20Auto%20Open)/demo.htm
Readonly: http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic,%20ReadOnly%20Auto%20Open%20plus%20Disabled%20Ranges)/demo.htm

Does this work better for you?

@frastlin
Copy link

yes, that's almost perfect. The only thing is that the aria-expanded attribute doesn't show collapsed when I arrow down to the button. Everything else works perfectly.

@shirsha
Copy link

shirsha commented Mar 31, 2019

Please see the following comments regarding the date picker:
• Format (mm/dd/yy) is present in the form of a placeholder.
• NVDA/Firefox and NVDA/Chrome skips the "Date" heading, the date input field and the "pick a date" button in virtual mode.
• In IE11, user is unable to access the calendar dialog via keyboard or JAWS. The dialog is not opened when the user tabs to input field.
• JAWS/IE11 narrates the date input field as "date link".
• JAWS/IE11 narrates the "pick a date" button as combo box dialog in virtual mode.
• Keyboard only and screen reader user is unable access the date picker dialog once the dialog is closed via [esc] or "cancel" button. They have to tab out of the input field and tab back to it to access the dialog.
• "Pick a date" button does not pass the required color contrast ratio of 3:1
• Keyboard user and screen reader users (in forms mode) unable to access the "Pick a date" button as it has tabindex of "-1"

@jongund
Copy link
Contributor

jongund commented Apr 1, 2019 via email

@mbgower
Copy link

mbgower commented Apr 11, 2019

Nice prototype! A couple of comments:

  • With that nice rich calendar UI, why not throw in a Help button to tell a keyboard user about all the keyboard interactions? Would be very unobtrusive and a nice precedent to set.

  • I didn't feel like the dropdown icon gave me enough of a visual hint that I moved to the calendar with a down arrow. I don't have anything super helpful to suggest at this second (other than maybe adding some actual text about that shortcut; especially if you do give an easy affordance to more keyboard help once in, that is the only real thing that needs to be intuitive).

  • On consideration, I think the fact the calendar appeared on focus was what threw me off a bit here. If it was a second tabstop you could just make the calendar open on Enter and put focus right in it. Was that tried? I can't see a usability issue with that. It's not like many UIs will have tons of date entry fields :)

@mbgower
Copy link

mbgower commented Apr 11, 2019

BTW, @mcking65 , I recognized your fingerprints all over this. Takes me back to a few sessions we spent on this at IBM.

@a11ydoer
Copy link
Contributor

@jongund @mcking65 and I reviewed the example together. Updates by Jon are coming up. (ie. Two of them are 1)removing aria-expanded and 2)adding autocomplete in input type="text")

@a11ydoer
Copy link
Contributor

Updated example by @jongund This will be discussed at ARIA -APG meeting on May 21, 2019
https://raw.githack.com/w3c/aria-practices/issue34-date-picker-examples/examples/datepicker/datepicker-combobox.html

@smhigley
Copy link
Contributor

From the meeting: one of the questions was whether the supplemental button next to the input should exist as a semantic button. Keeping it a <button> means that there will be two form controls exposed to screen readers for the one calendar control.

There is already the guideline that there should be one tab stop for the control. Should there also be pattern guidance for only exposing one semantic form control per combobox?

@jnurthen
Copy link
Member

In the current example the keyboard pops up on iOS when selecting a date in the calendar. Suggest not moving focus to the text field to avoid this problem.

@mcking65 mcking65 modified the milestones: 1.1 APG Release 4, 1.2 CR Aug 14, 2019
@mcking65 mcking65 linked a pull request Apr 14, 2020 that will close this issue
6 tasks
@mcking65 mcking65 removed a link to a pull request May 26, 2020
6 tasks
mcking65 added a commit that referenced this issue May 26, 2020
* Add Initial Cut of Date Picker Example (pull #839)

For issue #34, add a directory for datepicker examples and a first cut of code.

* Date Picker Example: Add link to development issue

* updated datepicker example and documentation

* fixed broken reference

* made updates to the documentation

* made updates to the documentation

* made updates to the documentation

* made updated code

* updated example

* updated code

* fixed problem with document clicks when date picker is open

* fixed problem with document clicks when date picker is open

* updated month year title

* improved source code documentation

* focus returns to textbox and added Home and End key commands for first and last day of the week

* edited description of example

* updated documentation

* updated documentation

* updated documentation

* fixed some bugs

* fixed some bugs

* removed some debugging code

* validated js and css code

* fixed bug

* added two regression tests

* updated keyboard behavior for opeing the datepicker

* updated date picker example to support keyboard announcements

* updated date picker example to support keyboard announcements

* updated date picker example to support keyboard announcements

* added down arrow key

* fixe bug with onclick

* updated click event on date to put date in textbox and close dialog

* down arrow appears on input focus

* updated click behaviors for input and calendar button

* updated datepicker document click event to handle clicking in textbox

* updated datepicker document click event to handle clicking in textbox

* updated code for down arrow in textbox

* updated example CSS

* updated code for down arrow in textbox

* fixed bug with document click event for dialog

* fixed interation bugs and added accessibilty feature description

* updated documentation, fied bugs and added a menu button date picker

* fixing mouse interaction issues

* fixed mouse bugs with date picker example

* cleaning up some of the code

* added feature to move to the next or previosu month when clicking on a disabled date

* changed header cells from using aria-label to abbr attribute

* fixed bugs with buttons for changing the next/previous year and month buttons

* fixed bug with next/previous buttons when focus is in the textbox

* created intial example of menu button for opening date picker

* added a file to support spin buttons

* initial implementation of a datepicker using spin buttons

* added documenation about values wrapping for day and month

* added documenation about values wrapping for day and month

* button label is updated with current date information

* button label is updated with current date information for combobox too now

* Move spinbutton and combobox examples

Moved the combobox datepicker to the aria 1.1 combobox directory.
Move the spinbutton date picker to new branch issue125-spinbutton-datepicker-example.

* Remove files copied to new issue1046-datepicker-dialog branch

* updating example to be compatible with date gird used in dialog date picker example

* fixed css bug

* added message live region to dialog

* fixed some bugs related to messages

* updated documentation on live regions

* updated regression test file for noew location of example and added a few tests for combobox

* removed aria-controls from buttons in the dialog to change the month/year and updated the file names to be compatible with other combox file names

* test commit

* test commit 2

* updated date picker code to use the Date object like the datepicker dialog example

* improved code by adding helper functions and removing a redundant function

* updated file name to be consistent wih other examples

* restored previous file name for compatibility with ava testing

* improved code readibility by using helper function to test if same month

* removed some unused variables

* removed unused properties and used helper function to compare days

* updated docuemntation and added ids for developing regression tests

* started integration of dialog box regression tests

* button label now updates with the selected date information

* updated link to provide feedback to point to th epull request

* removed aria-expanded from button

* updated method names to be more consistent and descriptive

* updated documentation

* updated documentation

* updated documentation

* updated documentation

* updated properties to move role and arai-expanded to input box, changed aria-owns to aria-controls and removed disabled days form the date grid

* updated some of the tests

* updated tests and fixe a tabindex bug

* removed some unused code

* removed unused functions

* updated CSS for hding disabled dates

* fixed data-date attribute computation

* fixed html validation bugs

* fixed some bugs

* restored

* restored

* restored

* updated test cases

* Change version in title and footer from 1.1 to 1.2

* changes file name

* updated code

* fixed bug with last row being shown

* added updating button label based on selected date

* This test is no longer needed

* changed design to remove buttons from gridcells

* Added role gridcell to support validator bug for not recognizig `td` in contect of a `role=grid` as a `gridcell`

* improved high contrast of combobox buton svg image

* added role=groidcell to pass html validator

* fixed bug with aria-selected

* fixed bug with aria-select following focus

* separated space and enter behavior and fixed bug with focus on combobox when page loads

* Updated links to source files

* Fixed broken link

* updated tests and added keyboard event for button

* updated test using the SPACE key

* updated focus styling

* Apply editorial suggestions from code review by @carmacleod

Co-Authored-By: Carolyn MacLeod <[email protected]>

* updated focus styling to use solid borders

* updated styling of date with tabindex=0

* updated regression tests coverage to inlcude missing tests

* removed reference to undefined object

* Add missing data-test-id for tabindex=-1

* Add test for month-year-button-space-return

* removed code to update button with the current date

* Fix an assertion in the month-year-button-space-return test

* Use await where appropriate

Tests were sometimes passing and sometimes failing in CI.
I think the reason may be that the code wasn't using await consistently.

* fixed regression test to use Key.SPACE instead of space character

* made improvements to high contrast support

* updating regression tests

* updated regression test to use queryElements and remove t.plan, but getting rejected promise errors

* updated documentation on high contrast support

* updated documentation on high contrast support

* updated documentation on high contrast support

* updated documentation on high contrast support

* Fix tests to use queryElements correctly

* Fix spelling errors caught by npm run lint:spelling

* Add stubs for missing tests

* removed code for an unused live region for a combobox message

Co-authored-by: Matt King <[email protected]>
Co-authored-by: Carolyn MacLeod <[email protected]>
Co-authored-by: Simon Pieters <[email protected]>
mcking65 added a commit that referenced this issue Jul 1, 2020
* Add Initial Cut of Date Picker Example (pull #839)

For issue #34, add a directory for datepicker examples and a first cut of code.

* Date Picker Example: Add link to development issue

* updated datepicker example and documentation

* fixed broken reference

* made updates to the documentation

* made updates to the documentation

* made updates to the documentation

* made updated code

* updated example

* updated code

* fixed problem with document clicks when date picker is open

* fixed problem with document clicks when date picker is open

* updated month year title

* improved source code documentation

* focus returns to textbox and added Home and End key commands for first and last day of the week

* edited description of example

* updated documentation

* updated documentation

* updated documentation

* fixed some bugs

* fixed some bugs

* removed some debugging code

* validated js and css code

* fixed bug

* added two regression tests

* updated keyboard behavior for opeing the datepicker

* updated date picker example to support keyboard announcements

* updated date picker example to support keyboard announcements

* updated date picker example to support keyboard announcements

* added down arrow key

* fixe bug with onclick

* updated click event on date to put date in textbox and close dialog

* down arrow appears on input focus

* updated click behaviors for input and calendar button

* updated datepicker document click event to handle clicking in textbox

* updated datepicker document click event to handle clicking in textbox

* updated code for down arrow in textbox

* updated example CSS

* updated code for down arrow in textbox

* fixed bug with document click event for dialog

* fixed interation bugs and added accessibilty feature description

* updated documentation, fied bugs and added a menu button date picker

* fixing mouse interaction issues

* fixed mouse bugs with date picker example

* cleaning up some of the code

* added feature to move to the next or previosu month when clicking on a disabled date

* changed header cells from using aria-label to abbr attribute

* fixed bugs with buttons for changing the next/previous year and month buttons

* fixed bug with next/previous buttons when focus is in the textbox

* created intial example of menu button for opening date picker

* added a file to support spin buttons

* initial implementation of a datepicker using spin buttons

* added documenation about values wrapping for day and month

* added documenation about values wrapping for day and month

* button label is updated with current date information

* button label is updated with current date information for combobox too now

* Move spinbutton and combobox examples

Moved the combobox datepicker to the aria 1.1 combobox directory.
Move the spinbutton date picker to new branch issue125-spinbutton-datepicker-example.

* Remove files copied to new issue1046-datepicker-dialog branch

* updating example to be compatible with date gird used in dialog date picker example

* fixed css bug

* added message live region to dialog

* fixed some bugs related to messages

* updated documentation on live regions

* updated regression test file for noew location of example and added a few tests for combobox

* removed aria-controls from buttons in the dialog to change the month/year and updated the file names to be compatible with other combox file names

* test commit

* test commit 2

* updated date picker code to use the Date object like the datepicker dialog example

* improved code by adding helper functions and removing a redundant function

* updated file name to be consistent wih other examples

* restored previous file name for compatibility with ava testing

* improved code readibility by using helper function to test if same month

* removed some unused variables

* removed unused properties and used helper function to compare days

* updated docuemntation and added ids for developing regression tests

* started integration of dialog box regression tests

* button label now updates with the selected date information

* updated link to provide feedback to point to th epull request

* removed aria-expanded from button

* updated method names to be more consistent and descriptive

* updated documentation

* updated documentation

* updated documentation

* updated documentation

* updated properties to move role and arai-expanded to input box, changed aria-owns to aria-controls and removed disabled days form the date grid

* updated some of the tests

* updated tests and fixe a tabindex bug

* removed some unused code

* removed unused functions

* updated CSS for hding disabled dates

* fixed data-date attribute computation

* fixed html validation bugs

* fixed some bugs

* restored

* restored

* restored

* updated test cases

* Change version in title and footer from 1.1 to 1.2

* changes file name

* updated code

* fixed bug with last row being shown

* added updating button label based on selected date

* This test is no longer needed

* changed design to remove buttons from gridcells

* Added role gridcell to support validator bug for not recognizig `td` in contect of a `role=grid` as a `gridcell`

* improved high contrast of combobox buton svg image

* added role=groidcell to pass html validator

* fixed bug with aria-selected

* fixed bug with aria-select following focus

* separated space and enter behavior and fixed bug with focus on combobox when page loads

* Updated links to source files

* Fixed broken link

* updated tests and added keyboard event for button

* updated test using the SPACE key

* updated focus styling

* Apply editorial suggestions from code review by @carmacleod

Co-Authored-By: Carolyn MacLeod <[email protected]>

* updated focus styling to use solid borders

* updated styling of date with tabindex=0

* updated regression tests coverage to inlcude missing tests

* removed reference to undefined object

* Add missing data-test-id for tabindex=-1

* Add test for month-year-button-space-return

* removed code to update button with the current date

* Fix an assertion in the month-year-button-space-return test

* Use await where appropriate

Tests were sometimes passing and sometimes failing in CI.
I think the reason may be that the code wasn't using await consistently.

* fixed regression test to use Key.SPACE instead of space character

* made improvements to high contrast support

* updating regression tests

* updated regression test to use queryElements and remove t.plan, but getting rejected promise errors

* updated documentation on high contrast support

* updated documentation on high contrast support

* updated documentation on high contrast support

* updated documentation on high contrast support

* Fix tests to use queryElements correctly

* Fix spelling errors caught by npm run lint:spelling

* Add stubs for missing tests

* removed code for an unused live region for a combobox message

Co-authored-by: Matt King <[email protected]>
Co-authored-by: Carolyn MacLeod <[email protected]>
Co-authored-by: Simon Pieters <[email protected]>
michael-n-cooper pushed a commit that referenced this issue Jul 7, 2020
Add combobox date picker example(pull #1413)

Resolves #34 by adding a combobox example that opens a dialog containing a calendar grid.

Co-authored-by: Jon Gunderson <[email protected]>
Co-authored-by: Carolyn MacLeod <[email protected]>
Co-authored-by: Simon Pieters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Example Page Related to a page containing an example implementation of a pattern
Development

No branches or pull requests