User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

1. On Linux, start the Orca screen reader, on Windows, start NVDA screen reader
2. Create a new event
3. Tab with keyboard until the fields starts
4. Press left or right arrow to move the cursor inside the date field (it's the usual way for a blind person to re-read what he has write)

Actual results:

At step 3 the screen reader stays silent so a blind person cannot determine what content in the date field
At step 4 the screen reader stays silent

Both steps 3 and 4 works on Thunderbird 60 with the current Lightning version 6.2.4

Expected results:

At step 3 the screen reader should read the content of the "date" field,
At step 4 the screen reader should read the character where the caret/focus has moves on,

As lightning is intended to manage calendar and setting a date is indispensable to able to do this feature I suggest to mark this issue has a critical issue.

In the accessibility inspector of GNU/Linux (Accerciser) previously in TB 60 I can see an accessible text entry which emitted events whereas on TB 66 there is no text entry for the date and time combo box and consecutively there is no text change events emitted.

For reminder, the screen reader and all assistive technologies base there behavior on the accessibility tree.
For the step 4 the screen reader needs to be aware if the caret has moved. You can compare with Thunderbird to confirm what I tell you.

Thanks in advance.

Best regards,
Alex.

Hello,

I am afraid this will be difficult to pin point.

In this build date entry field in the new calendar event dialog is accessible while typing: https://download-installer.cdn.mozilla.net/pub/thunderbird/nightly/2018/08/2018-08-26-13-11-42-comm-central/thunderbird-63.0a1.en-US.linux-x86_64.tar.bz2

In this build it is no longer accessible while typing: https://download-installer.cdn.mozilla.net/pub/thunderbird/nightly/2018/09/2018-09-09-10-01-30-comm-central/thunderbird-64.0a1.en-US.linux-x86_64.tar.bz2

There is only 1 build in between and that one crashes for me so I am unable to test it for this issue.

For the end user the impact can be broken down to these two points:

• When the combobox is focused it is missing name / label and a value.
• When editing the text there is no feetback.

When the combobox is collapsed pressing any of the arrow keys expands the combobox to a real calendar control where one can navigate by days (left and right arrows) and by weeks (up and down arrow). This is accessible. Abbreviated week days, month days and week numbers are provided this way. Selecting dates like this is very convenient (at least for me) however being able to type exact date e.g. a date in the future is also very common use case.

It's roughly this many change sets.... https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2018-08-26&enddate=2018-09-10
Is there a way to somehow specify a better filter so we can only look at calendar changes?

Hi,

In the nightly produced betwen last Thursday and today, the bug is fixed. Thanks!

Regards

Hello JorgK,

Are you aware of a specific fix or is it just a good side-effect that has fixed ?

Could we should fix this so?

Best regards,
Alex.

I don't know, Richard/Geoff, are we aware of how this got fixed?

Maybe from one of our editable menulist patches we landed to fix the menulist to CE patch on m-c.

Hello,

I am not really sure this is fixed properly.
Please reread my comment I have posted earlier to this bug. I described that it is possible to expand date entry field and use arrow keys to select a date in a calendar view navigating either by days or by weeks.
Now this is no longer possible and the date entry field is working like an edit field i.e. it can't be expanded by using the keyboard. At least it's not obvious to me.

Therefore in order to fix this properly I'd first like to hear what's the intended behaviour and after that we should discuss if all the functionality is accessible to keyboard only users and AT users.

Those widgets need an overhaul (bug 1524456), so I'd hold off calling this either way until that is done.

Hello,
The bug 1524456 is now fixed and the widget overhaul related changes are checked in.
Unfortunatelly related to this issue the behaviour has not changed.
So let me ask again:
When the date and time picker comboboxes are collapsed are they supposed to be editable i.e. can I just type in the date or time manually?

And to describe the behaviour taking into account changes that just have happened:

• When the date / time pickers are collapsed they expose no name / value / text to screen readers. I do know I have focused a combobox and that it is collapsed but I don't know what is its label nor its text or value.
• When the combobox is expanded by pressing alt+down arrow I can use all the arrow keys to navigate over a mini calendar, that's amazing.
• Once I am done with the selection I can confirm my choice by pressing the enter key and the new value is assigned. It would be nice if pressing esc key would close the mini calendar without applying the choice.
• The original behaviour @alexarnaud and JeanPhilippe don't like is still there eventhough temporary it was not there while the widgets overhaul has been worked on.

Hi,

The bug appears again in last nightly... :)

Regards

(In reply to Jean-Philippe MENGUAL from comment #4)

Hi,

In the nightly produced betwen last Thursday and today, the bug is fixed. Thanks!

Regards

We should look into this for TB 68 / Cal 7.0. Magnus, should we assign someone to all the accessibility issues left, there aren't many.

This fixes the reading of the current value in all menulists, and collapses the date picker when escape is pressed.

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/2dc0ef5baee8
Fix date/time picker for screen readers. r=mkmelin

Hi, for me the bug is fixed, as a screen reader user has means to change the dat and time typing them in the appropriat edit reas.

Peter, could you tell me your opinion about this?

Regards

Hello,

The change that has just been checked in is amazing.
I know you may think I'm too picky this time but It would be even better to create a follow up issue.
Now both widgets date picker and time picker consume two focusable elements in the tab order navigation.
For date picker thats okay as there is an expandable combobox that's pops up a calendar and editable text entry field where we can put down the exact date. Editing with the cursor keys is working fine when testing with orca on linux.
For time picker there is the same pair of focusable fields. When expanding the combobox no selection changes are communicated to accessibility apis even when pressing arrow keys.
So I'm not sure what's most appropriate here: making this part more accessible if there is indeed something to present, removing tabIndex on that element so it won't be focusable, or entirely hiding it to screen reader users.
Input from someone who can describe the intended behaviour would help to clear this up.
Still the functionality is now all great. What I am suggesting is just a bit of polishing.

Thanks

Thanks Peter, we already have bug 1526552 on the time picker. It's on my radar to fix but I wanted to see how this one went first.

Okay then. As always I haven't looked at the related issues in advance.
It's all great for me by knowing it's on your todo list.
Typing intothe editfield - requestedby AlexandJeanPhilippe as well assesctodismissrequestedbyme is allworking fine.

Thanks and greetings

TB 68 beta 2 / Cal 7.0:
https://hg.mozilla.org/releases/comm-beta/rev/57264934515548042137b9f39421bdd8285eac6f