OK.. So having played with the example highlighted above, I'm not happy that it is a viable alternative.. I managed to completely crash the browser on a few occasions trying to use it.

I believe this is an elegant solution to the problem highlighted in the accessibility report.

jQuery UI's datepicker is a popular component in wide use around the internet and is actually well regarded for it's accessibility options.

In this patch, I have chosen not to replace the standard datepicker, but rather supplement it's existing functionality by hijacking arrow key inputs when the datepicker is in focus and mapping them to a ctrl + arrow combination before forwarding them to the datepicker and as such enable no ctrl navigation of the datepicker.

We have removed the readonly in the past on feedback of a blind staff user we had for a while. Maybe we could do both? I know she had preferred being able to enter the date directly as it was much quicker and didn't require getting the calendar read out.

(In reply to Katrin Fischer from comment #4)
> We have removed the readonly in the past on feedback of a blind staff user
> we had for a while. Maybe we could do both? I know she had preferred being
> able to enter the date directly as it was much quicker and didn't require
> getting the calendar read out.

I did wonder about that myself.. my only fear there is that we get the date entered correctly.. we would need to take locale into account I believe and perhaps use an input mask to validate it?

I think this new code should be in calendar.inc instead of a separate file.

(In reply to Owen Leonard from comment #6)
> I think this new code should be in calendar.inc instead of a separate file.

Done

Erm.. where is the readonly actually set.. I can't seem to find it in our code?

Need help/input on the readonly aspect of this.. I still can't find where the readonly attribute is added to the fields for the page originally mentioned in this bug report but I have removed it for some other datepicker cases.

I'm not happy with the solution as it stands, however, as it enables the user to submit incorrect data which could result in either a server error in the best case or bad data in the worst.

Hi,

it looks like the readonly is set in the JavaScript:

        $(".toggle-hold-options").show();
        $(".hold-options").hide();
        $(".holddatefrom,.holddateto").prop("readOnly", true);

.holddateto is the one for "Hold not needed after:".

Owen, could you maybe help out here? I am not sure why this was added and if we have means to validate the field input.

Created attachment 109470 [details] [review]
Bug 26041: Enable keyboard navigation without 'ctrl'

This patch enables keyboard navigation using the arrow keys without the
need to hold the control key for the jQuery UI datepicker.

Test plan
1/ Navigate to an item in the opac and attempt to place a hold
2/ On the resultant screen, use keyboard navigation to trigger the 'Show
more options' dropdown.
3/ Focus on one of the date inputs using keyboard navigation.
4/ Use 'ctrl + arrow' keys to navigate the datepicker.
5/ Note that prior to the patch using 'bare' arrow keys does not trigger
anything
6/ Apply the patch and confirm that the datepicker can now be naviated
using the arrow keys without holding the ctrl key.
7/ Confirm that using the ctrl key combinations continue to work as
expected too.
8/ Signoff

Signed-off-by: Brandon J <brandon.jimenez@inLibro.com>

I have obsoleted the final patch with agreement from the sponsor.   Removing the readonly attribute had the side effect of also interrupting the flow for keybarod navigation as the same field would be editable twice in sequence (once via text entry and a second time via the datepicker widget).

Created attachment 109544 [details] [review]
Bug 26041: Enable keyboard navigation without 'ctrl'

This patch enables keyboard navigation using the arrow keys without the
need to hold the control key for the jQuery UI datepicker.

Test plan
1/ Navigate to an item in the opac and attempt to place a hold
2/ On the resultant screen, use keyboard navigation to trigger the 'Show
more options' dropdown.
3/ Focus on one of the date inputs using keyboard navigation.
4/ Use 'ctrl + arrow' keys to navigate the datepicker.
5/ Note that prior to the patch using 'bare' arrow keys does not trigger
anything
6/ Apply the patch and confirm that the datepicker can now be naviated
using the arrow keys without holding the ctrl key.
7/ Confirm that using the ctrl key combinations continue to work as
expected too.
8/ Signoff

Signed-off-by: Brandon J <brandon.jimenez@inLibro.com>

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Created attachment 109558 [details] [review]
Bug 26041: Enable keyboard navigation without 'ctrl'

This patch enables keyboard navigation using the arrow keys without the
need to hold the control key for the jQuery UI datepicker.

Test plan
1/ Navigate to an item in the opac and attempt to place a hold
2/ On the resultant screen, use keyboard navigation to trigger the 'Show
more options' dropdown.
3/ Focus on one of the date inputs using keyboard navigation.
4/ Use 'ctrl + arrow' keys to navigate the datepicker.
5/ Note that prior to the patch using 'bare' arrow keys does not trigger
anything
6/ Apply the patch and confirm that the datepicker can now be naviated
using the arrow keys without holding the ctrl key.
7/ Confirm that using the ctrl key combinations continue to work as
expected too.
8/ Signoff

Signed-off-by: Brandon J <brandon.jimenez@inLibro.com>

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

2 Questions:
1. Why is this change only affecting the OPAC?
2. To me it's still not really "accessible", if you create a new account the current date is selected. How do you pick a date from, say, year 1980? Select year dropdown list still cannot be selected.

Pushed to master for 20.11, thanks to everybody involved!

(In reply to Jonathan Druart from comment #18)
> 2 Questions:
> 1. Why is this change only affecting the OPAC?

Currently, I'm only working through accessibility issues raised in a report which was carried out against the OPAC. There is also a report being written currently for the staff client I believe at which time hopefully I can work through issue there as their own piece of work.

> 2. To me it's still not really "accessible", if you create a new account the
> current date is selected. How do you pick a date from, say, year 1980?
> Select year dropdown list still cannot be selected.

Fair point, though the 'up' and 'down' arrows can be used to quickly scroll between months, it's still not ideal.

I'll work on some additional improvements.

Actually.. those cases are already covered by default keybindings for the jQuery UI datepicker..

PAGE UP: Move to the previous month.
PAGE DOWN: Move to the next month.
CTRL + PAGE UP: Move to the previous year.
CTRL + PAGE DOWN: Move to the next year.
CTRL + HOME: Open the datepicker if closed.
CTRL/COMMAND + HOME: Move to the current month.
CTRL/COMMAND + LEFT: Move to the previous day.
CTRL/COMMAND + RIGHT: Move to the next day.
CTRL/COMMAND + UP: Move to the previous week.
CTRL/COMMAND + DOWN: Move the next week.
ENTER: Select the focused date.
CTRL/COMMAND + END: Close the datepicker and erase the date.
ESCAPE: Close the datepicker without selection.

What my patch does is allow the existing SHIFT + ARROW to continue working whilst also mapping it to allow for just ARROW for more natural navigation.. 

The real issue here, is that there's not a universally agreed upon standard set of keyboard navigation keys for accessible calendar widgets so we're just trying to support a sensible variety.

It may well be worth documenting these keyboard shortcuts somewhere though..

accessibility enhancement, choosing to backport:

backported to 20.05.x for 20.05.04

backported to 19.11.x for 19.11.10

Backported to 19.05.x branch for 19.05.15