431076 - Add keyboard navigation/accessibility for the calendar views

Status: NEW

(Calendar :: Calendar Frontend, defect)

Description

[Philipp Kewisch [:Fallen][📱📆]]

We should make the views more accessible. A first step is to make the views keyboard navigable.

Possible Implementation for month view:
  - Allow tabbing through month day boxes
  - Treat month day boxes as a rich list:
    o Arrow keys to navigate between events
  Pro: Probably easy to implement as accessible richlistboxes
  Con: Users need to tab through each day and cannot skip weeks

Alternative:
  - Allow tabbing to calendar-month-view
  - Use arrow keys to navigate between days
  - Shift focus to first event in box and allow tabbing through events
  - If it helps, make the month-view be an accessible pane, with subelements
  Pro: Easy navigation between days/weeks
  Con: Focus is shifted by script, which might not be optimal


Similar alternatives could apply for multiday views.

Aaron, Marco, may I ask you for your opinion?

Also, Christian, do you have a good idea how the views should look when focused, and also how event boxes should look when focused? This could of course depend on bug 430382.

Comment 1

[Christian Jansen]

It should be possible to "enter" the calendar grid by pressing F6.

 - An half hour slot should be focused
   (e.g. the upper left of the visible area) We should make use of
   the selection color to visualize this.

 - it should be possible to move the selection by using
   ARROW UP, DOWN, LEFT, RIGHT.

 - hitting RETURN should create an Event

 - hitting TAB should exit the grid and select the next event.

 - Shift TAB should select the previous event.

 - Hitting ESC jumps back into the grid , hitting ESC again exits the grid

 - An focused event should be highlighted by using the selection color

 - Hitting RETURN on an focused event should open the Event dialog

Comment 3

[Marco Zehe (:MarcoZ)]

The way I see it, we have three different parts to navigate: The days/weeks, the time slots within a day, and possible events.
1. Within the date navigation, up and down should select days. Left should skip a week back, right a week forward. CTRL+LEFT/right should skip months, CTRL+PAGE UP/PAGE DOWN could skip a year. As the selection changes, time slot and event views update with info for the selected date.
2. Within the time, up and down select time slots. ENTER creates a new event for the selected time slot.
3. Within the events, UP and DOWN select available events. These should be day-based, not timeslot-based, and the selection within the time slots should change when event selection is changed. ENTER should edit an event.

I believe escaping out of different levels may cause too much confusion than simply making these three areas tabbable.

Comment 4

[Pander]

see also https://bugzilla.mozilla.org/show_bug.cgi?id=471381 for proposed key bindings and screenshot of icons which need to be added to the calendar views.

Comment 5

[Philipp Kewisch [:Fallen][📱📆]]

A group of three students from Brazil in a course about open source is going to be working on this bug as a student-project. Looking forward to your patch(es), thanks Eduardo!

Comment 6

[Pander]

Hi all, any progress on this issue? Implementing this and what is documented in bug 471381 should offer trivial and intuitive calendar navigation which would greatly improve overall user satisfaction.

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

Not yet, the students are still working on some other bugs to get started. It is unfortunately not trivial to make the views accessible since their structure is quite complex.

Comment 9

[eric]

Being able navigate using the keyboard, from day to day in month view using the keyboard arrow keys, and from month to month using page up / page down, for example, is critical, in my opinion. I assume that is what this bug is about. 

This is standard usability. Ctrl-C doesn't even seem to work to copy an event from one day to another. I recommend addressing this soon to retain users.

Comment 11

[Nguyen Ngoc Trung]

I would like to try this.

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

That sounds great, I'm glad you are interested. Do you need help getting started here or do you want to try it on your own first?

I'd suggest you gather some ideas on how you'd like to fix this bug and send me a summary per email, so we can make sure that you are heading in the right direction before you start.

Comment 13

[Mohit Kanwal [:redDragon]]

Hi, is there a progress on this?

Comment 15

[Chen Wei]

Attachment: add keyboard navigation for Multiweek Month view

Since this bug has been silence for a while, and for us finger happy people, a calendar that can not navigate by keyboard is just not right:), hence this patch.

Left: to previous day
Right: to next day
Up: same day in previous week(7 days before)
Down: same day in next week

PageUp: previous month in month view, scroll one view up in multiweek view
PageDown: does the opposite

HOME: go to today

Comment 16

[Decathlon]

Comment on attachment 8379475 [details] [diff] [review]
add keyboard navigation for Multiweek Month view

This patch adds navigability with keyboards to month view and multiweek view.
We need a decision about how it should be handled overall given the request in comment 0,comment 1 and comment 3.

My personal observations: since we are here, at least we should add navigability also to day view and week view.

From the code POV I would add the handler (maybe only one handler with a switch-case statement for all the keys) in calendar-base-view. Also the method "navDay" could be added only once in calendar-base-view instead of repeat it almost similar for every binding. The various small functions that actually do the navigation by moving the selected day according to the kind of view, instead could be placed in their different bindings in calendar-views.xml (unless they are the same for all the views, in this case they could stay inside navDay() inside calendar-base-view.xml)

e.g. I could think to this function inside the binding id="calendar-multiweek-view" that responds to the page_up page_down keys

+       let visibleWeeks = cal.getPrefSafe("calendar.weeks.inview", 4);
+       let selectedDay = this.selectedDay.clone();
+       if (aNumber < 0) {
+           selectedDay.day -= 7 * visibleWeeks;
+       } else {
+           selectedDay.day += 7 * visibleWeeks;
+       }
+       this.goToDay(selectedDay);


and the other function that responds to the same keys inside the binding id="calendar-month-view"

+       if (aNumber < 0) {
+           this.moveView(-1);
+       } else {
+           this.moveView(1);
+       }

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

Hi Folks, thanks for looking into this. Generally, what Marco says is golden from an a11y standpoint so I would follow this as much as possible. I am not quite sure how he pictured switching between boxes, timeslots and events though. We don't support selecting timeslots yet, I think we should find an implementation that will easily allow us to add in time slots later on.

What you are doing is already a good start. We should go with this approach, see how it feels and then expand on that in a separate bug. If it doesn't work out, we can still change it. To summarize:

Left: to previous day
Right: to next day
Up: same day in previous week(7 days before)
Down: same day in next week

PageUp: previous month in month view, scroll one view up in multiweek view
PageDown: does the opposite

HOME: go to today (don't we already do this?)
ENTER: create new event in selected day/weekday

In a separate bug, we could do the following, ignoring the time slots until we support them:

TAB/Shift+TAB: Traverse selection:
  - The box itself (ENTER creates new event, arrows continue to select other boxes)
  - The time slots (ENTER creates new event, arrows select time slots)
  - The events     (ENTER modifies the event, arrows switch. Select first event in timeslot if applicable)
  - The next box   (rinse and repeat)

To make sure this works out for a11y, we can use aria-labels. I'm also fine with doing this separately:
  - selecting the view should mention the timeframe
     - day: the date
     - week: "week of (first day)"
     - multiweek: "weeks between (d1) and (d2)"
     - month: month name
  - selecting a box should be aria-labeled with the relative date and possibly the number of events
     - day: not applicable, but make sure the number of events was previously mentioned
     - week: weekday name ("3 events on Monday", ...)
     - multiweek: the date
     - month: the date
  - selecting timeslots should mention the timeslot start and number of events, possibly with 
    title if there is just one event.
  - selecting events should be aria-labeled with "(time): (title)" (possibly add location)

Comment 18

[Chen Wei]

Attachment: keyboard navigation

add keyboard navigation for all views.

Left: to previous day
Right: to next day
Up: same day in previous week(7 days before)
Down: same day in next week

PageUp: previous month in month view, scroll one view up in multiweek view
PageDown: does the opposite

HOME: go to today

In day view, the Up/Down key skips 7 days. This is strange but only skip 1 day is also unnatural, at least that is how I feel.

Because lightning already uses Ctrl-I and Ctrl-D to create new event and todo, the Enter key is not used.

Comment 19

[Decathlon]

Sorry for the late answer.

As far as I can see the patch works fine, it allows to navigate inside the views with the keyboard (although not on the tabs views).

The only problem I can find is in month view when trying to change the day month by month (with PAGE_DOWN/UP keys) on a selected day that doesn't belong to the displayed month, for example:
- display the month of August 2014 and select the 30th of July (without changing month);
- now press the PG-Down key;
--> instead of selecting the 30th of August, the view changes to September with no day selected.

This is the behavior of the function moveView() and it happens also when changing the month in month view with the navigation buttons, but maybe in that case it's less important because the goal is simply changing the month and not selecting a particular day.


What is really missing to fix completely this bug is a functioning navigation with the keyboard for the tabs of the calendar views, the same way for Thunderbird's tabs:
- pressing the TAB key should move the focus on the *selected* tab view; 
- once focused, should be possible to select another view by pressing the *arrows keys* left/right (at the moment the tabs get active but the view doesn't change);
- pressing another time the TAB key should be possible to move inside the selected view with the arrows keys like it is possible with this patch (currently the focus goes on the other tabs one by one before going inside the view).


(In reply to Chen Wei from comment #18)
> In day view, the Up/Down key skips 7 days. This is strange but only skip 1
> day is also unnatural, at least that is how I feel.
>

I agree with that, for me is fine. Using Up/Down keys in a different way could be possible only if there was some kind of slot (one hour?) selectable inside the selected day.

> Because lightning already uses Ctrl-I and Ctrl-D to create new event and
> todo, the Enter key is not used.

Let's wait for Philipp's opinion on that. Create an event/task with the keyboard is not a missing feature, but I have to admit the using the Enter key to create an event seems something of natural after the navigation with the keys in the in the view.

Comment 20

[Decathlon]

Comment on attachment 8416994 [details] [diff] [review]
keyboard navigation

Review of attachment 8416994 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/base/content/calendar-base-view.xml
@@ +750,5 @@
> +        aNumber is an integer, negative moves backward, positive moves forward
> +        -->
> +        <method name="navDay">
> +            <parameter name="aNumber"/>
> +            <body><![CDATA[

Please fix the indentation of all the block <method name="navDay"> and inside the block. Since there are different kind of indentations in the file, you can use the same in the code around yours.

@@ +779,4 @@
>            this.moveView(event.detail);
>          ]]>
>        </handler>
> +<!--

you can delete the code commented out

Comment 21

[Markus Adrario [:Taraman]]

Great to see progress on this!
May I suggest, that you add some mozmill-tests for the keyboard navigation.

If you haven't worked with Mozmill so far, I can offer to help you getting started.

Comment 22

[Chen Wei]

Attachment: keyboard navigation

This patch only fixed indentation and removed commented out code block.

I didn't find a way to use Enter key for creating new event so the Enter key is still unused. Besides, I guess the Enter key was not used in the first place is because it is hard to tell whether the user want create a new event, or new task, or open exist event/task.

How about move that "Tab" navigation into a new bug? The keyboard navigation in this patch is pretty simple and don't involve many logic and coding, the "Tab" navigation on the other hand, sounds complicate, it might need "tab" through minimonth, calendar views, Events and TODOs, today's pan.

As for the Mozmill test, it is a great tool but I wonder it might be overkill for this simple patch.

Comment 23

[Decathlon]

Comment on attachment 8440227 [details] [diff] [review]
keyboard navigation

Philipp,
this patch works fine, so I give a r+ but it covers only part of the requests in description i.e. the *navigability in the days* of all the views (but not through the views).

The only problem is that it introduces the tabbing through the events in the view, therefore, once you are in the view, you have to press the TAB key as many times as the numbers of events in the view before moving out the focus and going in the miniday (where there are four elements that are in the tabbing sequence but are not visible, but this is another issue). Moreover the events are not selected while tabbing.
I don't know if this issue is enough to wait for a more complete patch. In my opinion it could worth to push it as it is despite the tabbing through the events because it introduces "more" usability with the keyboard, although it doesn't close the bug (or it would open follow-up bugs).

Comment 24

[Markus Adrario [:Taraman]]

For comment #22
I would agree, that the test must not be done with this patch.
We can open a new patch for that and if you like work together on that.

Comment 25

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 8440227 [details] [diff] [review]
keyboard navigation

Review of attachment 8440227 [details] [diff] [review]:
-----------------------------------------------------------------

I have a little trouble testing this because OSX only has limited accessibility options and tabbing through events doesn't work there (expected). Given its an improvement already and its past TB31 anyway, I wouldn't mind taking this despite the tabbing issues. I'm a little wary of the events not being selected when tabbing through. What does happen when tabbing, is just the focus rectangle shown?

Comment 26

[Chen Wei]

(In reply to Philipp Kewisch [:Fallen] from comment #25)
> What does happen when tabbing, is just the focus rectangle shown?

Nothing happens when tabbing.

I imaging lightning has many layers of views. Before apply this patch, keyboard input works on topmost layer, and tabbing will select and cycle through Day/Week/Multiweek/Month tabs of the view. This patch changes the calendar-views.css so that keyboard input "penetrate" the topmost layer into the layer where calendar-month-base-view etc.al belong. Because keyboard input is captured by this layer and tab key is not used(yet) by this layer, nothing happens when tabbing, no even the cycling of Day/Week/Multiweek/Month tabs, at least that is what I observed on Linux.

Comment 30

[Henry Wilkes (they/them) [:henry-x]]

After bug 1738689 I'll take a look at keyboard navigation options.

Comment 32

[chrizilla]

(In reply to comment #15 and comment #18 by Chen Wei)

add keyboard navigation for all views.

Left: to previous day
Right: to next day
Up: same day in previous week(7 days before)
Down: same day in next week

PageUp: previous month in month view, scroll one view up in multiweek view
PageDown: does the opposite

HOME: go to today

Incidentally, this is also the hotkey assignment expected by the majority of the closed duplicate bugs, e.g. bug 607572, bug 694910, bug 1904233, etc. ...

Comment 36

[chrizilla]

Attachment: Screenshot 1 (annotated): Happy guessing - where is the keyboard focus?? (Hint: it's neither C nor D!)

When tackling this bug, please also read the productive exchange in closed duplicate bug 1717363.

attaching image by Thomas D. (:thomas8) from comment #4 of closed duplicate bug 1717363, which reads as follows:

Created attachment 9229233 [details]
Screenshot 1 (annotated): Happy guessing - where is the keyboard focus?? (Hint: it's neither C nor D!)

Keyboard interaction with the main calendar view is very poor - pretty much non-existent.

It is totally not clear with all the colors in the week view where the focus is.

• Today (C in the screenshot) is over-emphasized by comparison and looks focused, but is not.
• The focused day (B) has focus but does not look focused: it's lacking a clear blue focus border (focus is actually there, as seen when you press Ctrl+I to add an event).
• Basic keyboard navigation from one day to another using cursor keys or page up/down is not possible.

We need to figure out some of the details, here's a start:

• Cursor left/right/up/down moves focus between calendar boxes horizontally/vertically according to their layout on screen.
• Page up/down changes the view to the next/previous time span per current view:
  • next/previous day on day view
  • next/previous week on week view
  • next/previous screen on multiweek
  • next/previous month on month view
• Remove the current wrong shortcuts [ / ] which is inconsistent with mail view behaviour

Comment 37

[chrizilla]

Attachment: https://bug1717363.bmoattachments.org/attachment.cgi?id=9229233

image attachment in previous comment didn't seem to work

Comment 39

[chrizilla]

added based on bug 1904233#comment 0