[WG: Accessibility] [maint] About datepickers

Wed Oct 26 15:42:11 PDT 2011

Beth,

I already did that search, that's why I decided to write to the list. 

I agree with you that it would be very difficult to find a solution for all Sakai technologies but, on the other side, I have one thing clear: if we don't try, we won't be successful. I think it's worth to try to find a common solution for JSF (for example) and see how it's going. If tool/project teams are using it in their developments, then we can try to move forward and do the same with other technology. 

It's very frustrating having to deal with the same f. date issues one time and another just becasue we are using different datepickers. Trying to find a standard is good. Once we have one, we'll try to push people to use it but, if we haven't one...we cannot encourage people to do nothing. 

As a good friend of mine use to say: let's move thing inch by inch. ;-)

Cheers,
   David
________________________________________
De: Beth Kirschner [bkirschn at umich.edu]
Enviado el: miércoles, 26 de octubre de 2011 19:51
Para: DAVID ROLDAN MARTINEZ
CC: Jean-Francois Leveque; Richwine, Brian L; Aaron Zeckoski; accessibility at collab.sakaiproject.org WG (accessibility at collab.sakaiproject.org); mt at collab.sakaiproject.org
Asunto: Re: [WG: Accessibility] [maint] About datepickers

If you search JIRA for "date widget", you'll find there's already quite a few existing JIRAs written up against this problem. At one point Fluid was proposing an internationalized date/time widget, but I lost track of whether it ever was implemented. There's also an old page on date/time widgets in confluence (https://confluence.sakaiproject.org/display/RES/Date+widget+improvements). It would be great if we could find a good solution or set of solutions -- it's been a longstanding problem -- but I'm skeptical we could find one solution that will work for velocity, jsp, jsf, rsf, wicket, ...

- Beth

On Oct 15, 2011, at 2:25 PM, DAVID ROLDAN MARTINEZ wrote:

> Hi all,
>
> I was thinking to develop a new datetimepicker widget to include it with the rest of sakai JSF widgets. Can anybody  point me to an accesible JS/AJAX datetimepicker or to any sample accessible datepicker HTML code I can use to design this new widget renderization, please? How about using RichFaces calendar: http://www.mastertheboss.com/web-interfaces/271-richfaces-calendar-example.html. Is the generated code accesssible? If it is, I can test i18n (we have in production for one month and haven't found any issue yet) and adopt it as a solution instead of developing a new one.
>
> One we have the solution, I'll include a short tutorials at i18n School site at confluence: https://confluence.sakaiproject.org/display/I18N/i18n+School.
>
> Thanks!!!!
>
> David
> ________________________________________
> De: Jean-Francois Leveque [jean-francois.leveque at upmc.fr]
> Enviado el: jueves, 13 de octubre de 2011 16:48
> Para: Richwine, Brian L
> CC: Aaron Zeckoski; DAVID ROLDAN MARTINEZ; accessibility at collab.sakaiproject.org WG (accessibility at collab.sakaiproject.org); mt at collab.sakaiproject.org
> Asunto: Re: [WG: Accessibility] [maint] About datepickers
>
> About the time picker, jQuery does not seem to have an official one.
>
> http://trentrichardson.com/examples/timepicker/ looks like a candidate
> for an js-illiterate like myself.
> http://www.yiiframework.com/extension/timepicker/, based on it supports
> more languages.
>
> Hope this helps.
>
> J-F
>
> On 13/10/2011 15:52, Richwine, Brian L wrote:
>> Yes, the jQuery date picker ties to a standard text input control. It would be great if the model input for the date was tied to the control through putting an aria-describedby attribute on the text input element.
>>
>> The jQuery date picker is keyboard accessible, assuming the operator knows the special hotkeys for operating it. I'll have Mary Stores test it soon using the JAWS screen reader, however at first glance it doesn't seem terribly screen-reader user friendly as it doesn't manage keyboard focus (if keyboard focus leaves the text box, the date picker popup disappears).
>>
>> The provided hotkeys are non-standard, and WCAG requires that the user is informed of any non-standard hotkeys that are required for operation (non-standard Web page navigation keys. i.e.: pretty much anything beyond tab, shift+tab, unmodified arrow keys, enter, and the space bar). At a minimum the hotkeys will need to be listed in the accessibility information in the help system.
>>
>> These are the provided keyboard shortcuts to operate the datepicker:
>>     page up/down - previous/next month
>>     ctrl+page up/down - previous/next year
>>     ctrl+home - current month or open when closed
>>     ctrl+left/right - previous/next day
>>     ctrl+up/down - previous/next week
>>     enter - accept the selected date
>>     ctrl+end - close and erase the date
>>     escape - close the datepicker without selection
>>
>> Silly question, is there a time picker widget to match the date picker widget in jQuery?
>>
>> I agree it would be great to standardize on one particular set of date/time widgets. Right now, it is nearly impossible to put text labels on the text input fields used with the rsf date picker. Now that the fckEditor is almost behind us, the unlabeled input fields for the date and time inputs are one of the more critical accessibility problems in Sakai. (https://github.com/rsf/RSFComponents/issues/1)
>>
>> -Brian
>>
>> -----Original Message-----
>> From: azeckoski at gmail.com [mailto:azeckoski at gmail.com] On Behalf Of Aaron Zeckoski
>> Sent: Thursday, October 13, 2011 8:38 AM
>> To: Richwine, Brian L
>> Cc: Jean-Francois Leveque; DAVID ROLDAN MARTINEZ; accessibility at collab.sakaiproject.org WG (accessibility at collab.sakaiproject.org); mt at collab.sakaiproject.org
>> Subject: Re: [WG: Accessibility] [maint] About datepickers
>>
>> The jquery one is just a field which can take text so that helps but I think it would be helpful to agree on the hints we should provide as well.
>>
>> For example, should there be text in the field to start or outside showing the accepted format (I like in but I suspect that is less accessible)? Should it just be a lonely input or should there be an icon (I like the icon because it seems more informative and inline with the rest of the industry)?
>>
>> Once we have this stuff decided, I think there should be a wiki page in confluence that explains how to embed the calendar in a tool. We could then port over the current core tools. The contrib/indie ones would probably be a lot slower to adopt it since they generally have to be compatible with a range of sakai versions but in a few years or so we might be able to get to a point where tools are generally using the same calendar picker.
>>
>> -AZ
>>
>>
>> On Thu, Oct 13, 2011 at 8:10 AM, Richwine, Brian L<brichwin at indiana.edu>  wrote:
>>> I'll take a look at the accessibility. Typically we've excused the accessibility of the date picker, as long as a person can freeform enter the date in the field (and appropriate help info tells them how to enter the date, or there is an existing default value that models the format, etc.). Navigating a calendar date picker just doesn't seem intuitive to users with screen-reading software. It would be great if it was keyboard accessible and tried to be usable for screen-readers too. However it is important to offer both.
>>>
>>> -Brian
>>>
>>> -----Original Message-----
>>> From: Jean-Francois Leveque [mailto:jean-francois.leveque at upmc.fr]
>>> Sent: Thursday, October 13, 2011 4:23 AM
>>> To: DAVID ROLDAN MARTINEZ
>>> Cc: mt at collab.sakaiproject.org; Beth Kirschner; Richwine, Brian L
>>> Subject: Re: [maint] About datepickers
>>>
>>> Hi David,
>>>
>>> http://jqueryui.com/demos/datepicker/#localization works in French, AFAICT.
>>>
>>> If Brian gives us good news about its accessibility, it would be great if other members of the i18n community could try it in their language before going further.
>>>
>>> Best,
>>>      J-F
>>>
>>> On 13/10/2011 09:48, DAVID ROLDAN MARTINEZ wrote:
>>>>
>>>>           Hi all,
>>>>
>>>>           Almost each Sakai tool uses a different datepicker and this makes very difficult to manage i18n bugs because we are always finding the same issues but in different datepickers. As you can imagine, this is very frustrating and increases the workload as it's needed to redo the same work for different datepickers.  Besides, this also decreases usability and accessibility, as users has to deal with several formats and ways of doing things.
>>>>
>>>>           I would like to propose to find a common solution for the whole Sakai or, at least, for those tool included in the main distribution (though, contrib tools can be encouraged to use the same solution). But, before to launch the request to sakai-dev and file JIRAs, I would like to get your feedback. My proposal is to use jquery datepicker: http://jqueryui.com/demos/datepicker, which is the only one I've found (if you know more, please, let me know) that is fully i18ned.
>>>>
>>>>           Best,
>>>>                David
>>> _______________________________________________
>>> accessibility mailing list
>>> accessibility at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>>>
>>> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
>
> --
> Jean-François Lévêque
> Responsable technique Sakai
> Université Pierre et Marie Curie
>
> --
> Jean-Francois Leveque
> Australe (local Sakai CLE) CTO
> University Pierre and Marie Curie
> France
>
>