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.

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

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.

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.

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!

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.

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.

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.

I would like to try this.

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.

Hi, is there a progress on this?

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 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); + }

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)

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.

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

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.

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 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).

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 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?

(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.