CiviCRM Community Forums (archive)

The pop-up date picker is not good for screen readers, how can we disable it from fields like birth date?

That did help, I removed the javascript it was adding, thank you!

sonicthoughts,
I don't know if this will help, but our folks had been complaining as well, mostly about not being able to manually input dates themselves.  So I went ahead and modified the file Dave refers to above and removed the readonly setting on the date form field.  Of course, what Dave mentions about validation is correct, allowing manual entry can cause some issues, but our folks were willing to live with those.

What I did was a quick hack (not sure if it's the best way to handle this):
1. copy jcalendar.tpl to your custom templates folder
2. find the following line (line 46 in my version of the file):
    {$form.$elementName.html|crmReplace:class:dateplugin}3. comment that and replace it with:
    {$form.$elementName.html|crmReplace:class:dateplugin|replace:'readonly="1"':''}
I think that's all it took.

I also changed some of the params to the datepicker widget to make it more user friendly for our folks (they didn't like the month and year dropdowns, made input confusing) - here are the params I use:
      cj(element_date).datepicker({
                                    closeAtTop        : true,
                                    dateFormat        : date_format,
                                    changeMonth       : false,
                                    changeYear        : false,
                                    constrainInput    : false,
                                    altField          : alt_field,
                                    altFormat         : 'mm/dd/yyyy',
                                    yearRange         : yearRange
                                });

So the combination of manual entry and the changes to the widget give us the best combo.  People who want to quickly change a year can do so manually, folks who want to skim through calendar dates can still do that with the widget.

Hope that helps a little.  Again, it's not a perfect solution because people can type in incorrect dates and the form will accept them, but in our case, the pros outweighed the cons.

can you check and see if the datepicker in Civi v3.3 / jQ 1.4 is better. You can try it out at http://sandbox.civicrm.org/

Would be great if some members of the community can group together and help improve the "date" situation. Would really help to make it more flexible but stil check the dates entered etc

lobo

Would be great if some members of the community can group together and help improve the "date" situation. Would really help to make it more flexible but stil check the dates entered etc.

Any thoughts on what that might look like, Lobo?

Sorry, I just meant, if folks wanted to get together to explore ways of improving the date picker, what might that discussion look like, how might it get started, etc?

-TM

If you're seeing CSS issues rendering the date picker in CiviCRM pages, this CSS fixed it for me.

Note that the body.section-civicrm class is present on my site but may not be on yours (unless you happen to have sections module installed, I think).

body.section-civicrm .ui-datepicker-header select {
    position: relative ;
}

What this does is override the CSS added by date_popup/themes/datepicker.css

There are two issues on this specific UI problem: http://issues.civicrm.org/jira/browse/CRM-5471 (removes date_popup/themes/datepicker.css from pages which are in CiviCRM path, and therefore potentially breaks Drupal datepickers in the sidebars or otherwise visible when on CiviCRM pages) and http://issues.civicrm.org/jira/browse/CRM-7133 (clone of the first issue, but for 3.2.x and with CSS-only fix recorded there). Latter issue needs an admin to move it from 3.1.x to 3.2.x as I can't do that on a cloned issue*.

* Apparently I have misunderstood the purpose of cloned issues, if they are locked to the original issue's details. What's the point of having a clone, if you can't mess with it?

Complaints got really bad so I tried below and it works well enough - thanks!  Note that you have to delete the civi cache for this to take effect (spent some time wasted on that ...) S.

sonicthoughts,
I don't know if this will help, but our folks had been complaining as well, mostly about not being able to manually input dates themselves.  So I went ahead and modified the file Dave refers to above and removed the readonly setting on the date form field.  Of course, what Dave mentions about validation is correct, allowing manual entry can cause some issues, but our folks were willing to live with those.

What I did was a quick hack (not sure if it's the best way to handle this):
1. copy jcalendar.tpl to your custom templates folder
2. find the following line (line 46 in my version of the file):
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin}3. comment that and replace it with:
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin|replace:'readonly="1"':''}
I think that's all it took.

I also changed some of the params to the datepicker widget to make it more user friendly for our folks (they didn't like the month and year dropdowns, made input confusing) - here are the params I use:

Code: [Select]

      cj(element_date).datepicker({
                                    closeAtTop        : true,
                                    dateFormat        : date_format,
                                    changeMonth       : false,
                                    changeYear        : false,
                                    constrainInput    : false,
                                    altField          : alt_field,
                                    altFormat         : 'mm/dd/yyyy',
                                    yearRange         : yearRange
                                });

So the combination of manual entry and the changes to the widget give us the best combo.  People who want to quickly change a year can do so manually, folks who want to skim through calendar dates can still do that with the widget.

Hope that helps a little.  Again, it's not a perfect solution because people can type in incorrect dates and the form will accept them, but in our case, the pros outweighed the cons.