Closed Bug 1707466 Opened 4 years ago Closed 4 years ago

html:input fields inside a tab are not usable via JAWS screen reader

Categories

(Thunderbird :: Disability Access, defect)

Product:
Thunderbird
Component:
Disability Access
Version:
Thunderbird 89
Platform:
x86_64
Windows 10
Type:
defect

Tracking

(thunderbird_esr78 unaffected)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
thunderbird_esr78 --- unaffected

People

(Reporter: ali-savas, Unassigned)

References

Details

(Keywords: access)

Description

The dialog for setting up existing email addresses is now an HTML dialog. To make such HTML dialogs properly accessible, JAWS uses a so-called virtual cursor to present the complete page, similar to a web page. When the virtual cursor is turned on, shortcut keys can be used to trigger certain functions of the screen reader, such as going to the next heading, going to the next input field, and so on. For example, in order to enter something in an input field, the so-called form mode must therefore be switched on. However, the virtual cursor can be turned off completely if desired, if the dialogs themselves have been designed to be very accessible and can be navigated well with TAB.

Apparently, no standard input field is used in this dialog, because if I try to enter something in the setup dialog, JAWS exits the form mode and activates the quick navigation keys. I have to turn off the virtual cursor so I can focus the input field with TAB and type something. However, the problem here is that unfortunately I cannot see what I have entered in this input field. Also the Braille display does not show me anything here.

The problem seems to be in the input fields of Thunderbird, which are created with HTML, because the same problem exists in the dialogs for the add-on search. On normal web pages, the input works as expected.

Steps to reproduce

Download and install JAWS

If not available, please download and install JAWS here:
https://jaws2021.vfo.digital/2021.2103.174.400/55D02B58-3740-458C-9206-93438FFD29BB/J2021.2103.174.400-Offline-x64.exe
Or
https://jaws2021.vfo.digital/2021.2103.174.400/55D02B58-3740-458C-9206-93438FFD29BB/J2021.2103.174.400-Offline-x86.exe

Then please start JAWS.

After installation

  1. In Thunderbird, go to "File", "New" and go to "Existing email account".
  2. The focus is automatically on the "Your Name" field and the form mode also turns on automatically. Try to enter a name here.

Result

JAWS immediately exits form mode and gives an error message or jumps somewhere, depending on which key is pressed first and whether there is a shortcut key for this or not. In my case, I enter "Ali" and the screen reader immediately jumps to the first radio button without entering a letter.

Expected

It should be possible to enter text normally, like in all other HTML input fields.

Do yo need to enter the "Forms mode" of JAWS? (Press Enter)

status-thunderbird_esr78: --- → unaffected

(In reply to Magnus Melin [:mkmelin] from comment #1)

Do yo need to enter the "Forms mode" of JAWS? (Press Enter)

As I said, normally the forms mode turns on automatically. But even if I activate the forms mode with Enter, JAWS always exits forms mode as soon as I want to enter a letter.

Thanks for the detailed report.
I'll take this.

Assignee: nobody → alessandro

I've filed bug 1707659 for keyboard access to the show/hide password button.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 1707659
Keywords: access, regression
Regressed by: 1697575

I'm able to consistently reproduce this error.
I also noticed that by pressing "F", JAWS should enter the Form mode since there's a form in the page and the focus is inside the first field of the form.
Instead, JAWS returns an error saying that there's not Form available in the page.

Typing in those fields doesn't work at all all letters are recognized as shortcuts to focus on other elements (eg. N to go to next element, B to go the the button, etc.)

Maybe the <html:input> prefix is causing these issues?

I setup the artifact build on my Windows VM so I can better troubleshoot this.
I'll see if by removing the <html: prefix I can fix JAWS not recognizing those input as standard.

Found the issue.
Having the autocomplete="off" attribute in the form element heavily interferes with JAWS to the point that is not possible to type anything.
Super weird.
I'll use this bug to improve other aspect of screen reading and make the account setup workflow more accessible.
Patch coming soon.

Can you please also remember that this behavior also occurs in the input field of the add-on dialog?

(In reply to Ali Savas from comment #8)

Can you please also remember that this behavior also occurs in the input field of the add-on dialog?

Will do, thanks for the reminder.

This issue goes deeper than I originally thought, and it's not a regression of recent changes but it seems that it has always been present.

Any html:input field is not usable (unable to type anything when focused) with JAWS screen reader on Windows.
This issue is present and reproducible on any input field in the Preferences or Account Settings page, subdialogs included.

The original "found issue" I wrote in comment 7 was a false positive as the issue doesn't present itself if JAWS is launched when Thunderbird is already running. If JAWS is launched before Thunderbird, the issue appears.
This looks pretty severe.

The issue doesn't seem to affect Firefox.

Severity: -- → S1
Flags: needinfo?(mkmelin+mozilla)
Keywords: regression
Priority: -- → P1
Summary: Dialog for setting up existing email addresses very difficult to access with JAWS → html:input fields inside a tab are not usable via JAWS screen reader

Sorry, no idea. You're saying you do not see it for the Firefox preferences?
:Jamie, any ideas?

Flags: needinfo?(mkmelin+mozilla) → needinfo?(jteh)

You're saying you do not see it for the Firefox preferences?

Correct, I checked also on Firefox nightly and I don't see the problem.

I don't have any idea why this would affect Thunderbird but not Firefox, and unfortunately, I don't have any cycles to look into this right now.

It'd be interesting to know whether this can be reproduced with the NVDA screen reader. If nothing else, if it can be reproduced, we'll be able to get a lot more useful logging out of NVDA.

Flags: needinfo?(jteh)

Also, is this rendered in the parent process or is it in a content (e10s) process?

This is rendered in the parent process.
I'll test NVDA later, thanks for the suggestion.

Using the NVDA screen reader works without issues.

(In reply to Alessandro Castellani [:aleca] from comment #10)

The original "found issue" I wrote in comment 7 was a false positive as the issue doesn't present itself if JAWS is launched when Thunderbird is already running. If JAWS is launched before Thunderbird, the issue appears.

JAWS has to be launched before Gecko applications, as JAWS depends on legacy Win32 widgets which haven't existed in Gecko for 10+ years, so Gecko has to "fake" these when it detects JAWS. NVDA does not depend on this. However, I suspect a bunch of stuff will break if you start JAWS after Thunderbird; e.g. reading email messages (which depend on the virtual cursor) probably won't work.

One other thing to try is whether you can enter text into the fields (and read it back with the cursor keys) with the virtual cursor disabled (JAWSKey+z). If you can, this would suggest this is specific to the virtual cursor.

You'll probably need to work with the JAWS vendor (Vispero) to figure out what's going on here. I have contacts there I can introduce you to via private email, but given this does not impact Firefox, I can't put much time into this beyond that.

Thank you so much for these great pointers, James.
Yes please, go ahead and introduce me to your contacts via email, I'll try to deal with this issue and work with them trying to find the root of the problem.

Thank you again for your help.

One other thing to try is whether you can enter text into the fields (and read it back with the cursor keys) with the virtual cursor disabled (JAWSKey+z). If you can, this would suggest this is specific to the virtual cursor.

Confirmed! Disabling the virtual cursor allows to type in all forms and fields, and the typed text can be read back when moving with the cursor key.

(In reply to Alessandro Castellani [:aleca] from comment #19)

One other thing to try is whether you can enter text into the fields (and read it back with the cursor keys) with the virtual cursor disabled (JAWSKey+z). If you can, this would suggest this is specific to the virtual cursor.

Confirmed! Disabling the virtual cursor allows to type in all forms and fields, and the typed text can be read back when moving with the cursor key.

The problem with this method, however, is that the entered characters cannot be read with a Braille display. This should also be mentioned at Vispero, should you collaborate.

The problem with this method, however, is that the entered characters cannot be read with a Braille display. This should also be mentioned at Vispero, should you collaborate.

Thanks Ali for the info.
Indeed, the disabling of the virtual cursor is not a solution to the problem, it was just a confirmation that the issue relies on that specific JAWS feature in order to better troubleshoot it.

I'm in contact with Vispero and they're currently testing the error with beta and nightly.
Hopefully, we can quickly find the issue and solve it.
Stay tuned.

Indeed, the disabling of the virtual cursor is not a solution to the problem, it was just a confirmation that the issue relies on that specific JAWS feature in order to better troubleshoot it.

If an HTML application is well programmed and everything is accessible via TAB etc., the virtual cursor is actually no longer needed. This can be switched off with the definition "Application", because JAWS then assumes a native application. This is necessary for example in the later message list, if this is no longer based on XUL, but also on HTML.

I'm in contact with Vispero and they're currently testing the error with beta and nightly.
Hopefully, we can quickly find the issue and solve it.
Stay tuned.

A few years ago I worked for Freedom scientific Germany (now Vispero brand) for six and a half years and I know some people there. I am confident that the problem will be solved.

FYI: JAWS has extra customizations (scripts) for Thunderbird. I have renamed them on a trial basis to rule out that this problem is caused by the scripts. The problem does not seem to be caused by the scripts, because even after renaming the scripts the same problems occur. So the problem seems to be deeper rooted in JAWS and Thunderbird.

Good and bad news!

Good news, it's not a Thunderbird issue but a JAWS issue that they will fix in the next release.
Here's an excerpt from Vispero:

Turns out to be a change to a single JAWS configuration file to get things to work. In the past, we did special things for Thunderbird that are no longer needed and caused problems with 78.
I set up a mailbox, read a couple of messages, and composed one and didn’t see any issues jump out.

And for the bad news:

We’ll get this change in for our July update.

So, a bit annoying that our standard HTML input fields in a tab are not working, but at least this issue is limited to beta and it should be resolved before the next ESR.

Should we leave this bug open until the new JAWS release?

Should we leave this bug open until the new JAWS release?

My suggestion would be that we leave this issue open and see if the new JAWS version has solved the problem or if something still needs to be done on our end.

Let's leave this open, but I'll remove it from being assigned to myself as I can't fix it.
I'm also removing Priority and Severity flags since the issue is not caused by Thunderbird as per comment 23.

Assignee: alessandro → nobody
Severity: S1 → N/A
Status: ASSIGNED → NEW
Priority: P1 → --
No longer regressed by: 1697575

This bug has been fixed with JAWS version 2021.2107.12 and can be closed.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.