Bug 26041 - Accessibility: The date picker calendar is not keyboard accessible
Summary: Accessibility: The date picker calendar is not keyboard accessible
Status: Pushed to oldoldstable
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 26040
  Show dependency treegraph
 
Reported: 2020-07-22 10:39 UTC by Martin Renvoize
Modified: 2020-09-20 19:25 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:
20.11.00, 20.05.04, 19.11.10, 19.05.15


Attachments
Bug 26041: Enable keyboard navigation without 'ctrl' (2.45 KB, patch)
2020-07-22 12:34 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26041: Enable keyboard navigation without 'ctrl' (2.01 KB, patch)
2020-07-24 07:17 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26041: Remove readonly flag (2.43 KB, patch)
2020-07-24 07:33 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26041: Remove readonly flag (2.49 KB, patch)
2020-08-19 15:59 UTC, Brandon J
Details | Diff | Splinter Review
Bug 26041: Enable keyboard navigation without 'ctrl' (2.06 KB, patch)
2020-09-02 07:09 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26041: Enable keyboard navigation without 'ctrl' (2.11 KB, patch)
2020-09-02 14:39 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 26041: Enable keyboard navigation without 'ctrl' (2.17 KB, patch)
2020-09-02 17:55 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2020-07-22 10:39:04 UTC
The ‘Reservation not needed after:’ edit field and accompanying date picker can only be
navigated using the ‘Ctrl’ and arrow keys. This means that some keyboard only users may
not be able to populate the edit field independently.

To replicate:
1/ Search for an item using quick search and reserve it from the results page.
2/ Confirm the reservation
3/ Attempt to navigate the datepicker via the keyboard without holding the ctrl key

Solution:
Ensure all interactive page elements are operable via standard keyboard commands. Also,
consider implementing an accessible date picker. For example:
https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

Alternatively, allow users to enter a date into the form field by removing the ‘read-only’
attribute.
Comment 1 Martin Renvoize 2020-07-22 10:52:30 UTC
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.
Comment 2 Martin Renvoize 2020-07-22 12:34:45 UTC Comment hidden (obsolete)
Comment 3 Martin Renvoize 2020-07-22 12:37:31 UTC
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.
Comment 4 Katrin Fischer 2020-07-22 20:33:58 UTC
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.
Comment 5 Martin Renvoize 2020-07-23 13:26:12 UTC
(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?
Comment 6 Owen Leonard 2020-07-23 14:34:27 UTC
I think this new code should be in calendar.inc instead of a separate file.
Comment 7 Martin Renvoize 2020-07-24 07:17:40 UTC Comment hidden (obsolete)
Comment 8 Martin Renvoize 2020-07-24 07:17:56 UTC
(In reply to Owen Leonard from comment #6)
> I think this new code should be in calendar.inc instead of a separate file.

Done
Comment 9 Martin Renvoize 2020-07-24 07:18:38 UTC
Erm.. where is the readonly actually set.. I can't seem to find it in our code?
Comment 10 Martin Renvoize 2020-07-24 07:33:40 UTC Comment hidden (obsolete)
Comment 11 Martin Renvoize 2020-07-24 07:36:06 UTC
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.
Comment 12 Brandon J 2020-08-19 15:59:03 UTC Comment hidden (obsolete)
Comment 13 Katrin Fischer 2020-08-22 14:32:14 UTC
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.
Comment 14 Martin Renvoize 2020-09-02 07:09:08 UTC
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>
Comment 15 Martin Renvoize 2020-09-02 07:11:33 UTC
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).
Comment 16 Owen Leonard 2020-09-02 14:39:15 UTC
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>
Comment 17 Nick Clemens 2020-09-02 17:55:10 UTC
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>
Comment 18 Jonathan Druart 2020-09-03 11:47:11 UTC
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.
Comment 19 Jonathan Druart 2020-09-03 13:04:42 UTC
Pushed to master for 20.11, thanks to everybody involved!
Comment 20 Martin Renvoize 2020-09-03 16:27:12 UTC
(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.
Comment 21 Martin Renvoize 2020-09-03 16:31:40 UTC
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..
Comment 22 Lucas Gass 2020-09-14 21:53:12 UTC
accessibility enhancement, choosing to backport:

backported to 20.05.x for 20.05.04
Comment 23 Aleisha Amohia 2020-09-15 11:51:06 UTC
backported to 19.11.x for 19.11.10
Comment 24 Victor Grousset/tuxayo 2020-09-20 19:25:06 UTC
Backported to 19.05.x branch for 19.05.15