[WG: Accessibility] Accessibility] [maint] About datepickers

Thu Oct 13 09:41:43 PDT 2011

Oh, it isn't just JAWS that uses those. For most of them, it is the browsers themselves that use the keys chosen by the date picker's writers. Several of them are the keys that everyone would be using for navigating inside of text fields, if they knew their keyboard shortcuts. While JAWS users can always prefix any key with the JAWS key pass through key combination, it isn't needed on all of these. Though it might be easiest to tell them to.

Did you get a chance to try using it with JAWS? Given that the datepicker doesn't appear immediately following the text input in the source (the code for it gets appended to the bottom of the page in a div element), focus isn't moved to the new elements, it disappears when the text input loses focus, and the month isn't a caption for the table or a table header or a heading, it has other issues that go beyond the chosen hotkey assignments. When the JAWS screen-reader gets to it, it simply says "Date colon edit", and since the inserted date content is at the bottom of the page, I doubt that a screen-reader user who is blind will never know the date widget is even there. They will just be confused by why they are limited to certain characters when typing input and may inadvertently insert a date in the field without knowing it. 

That last one is the biggest problem I see, that if the screen-reader user doesn't put any content in the text box and presses Enter, they are going to be surprised and confused as to why a date suddenly appeared in the text box (if they even notice it did -- JAWS won't automatically announce it).

-Brian

-----Original Message-----
From: rjc at mit.edu [mailto:rjc at mit.edu] 
Sent: Thursday, October 13, 2011 12:14 PM
To: Richwine, Brian L
Subject: Re: Accessibility] [maint] About datepickers

Just have to chime in here...

Yes, the jQuery date picker has shortcut keys, but Jaws uses all of them both for navigating virtual documents (i.e. role="document"), and for navigating inside text fields (standard windows control - happens when focus is on the control and role="application" - so just sticking a role="application" on the date picker input box won't help).

You can use them, but you need to prefix each stroke with the Jaws "don't steel next input key" which is jawsKey+pound (i.e. insert+#).

Hope this helps.

-----Original Message-----
From: Richwine, Brian L
Sent: Thursday, October 13, 2011 9:52 AM
To: Aaron Zeckoski
Cc: Jean-Francois Leveque ; mt at collab.sakaiproject.org ; accessibility at collab.sakaiproject.org WG
(accessibility at collab.sakaiproject.org) ; DAVID at collab.sakaiproject.org
Subject: Re: [WG: Accessibility] [maint] About datepickers

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
_______________________________________________
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" 