1635552 - Menulist-editable custom element wrongly handles focus when the input field is visible

Status: RESOLVED DUPLICATE of bug 1697575

(Thunderbird :: Disability Access, defect, P1)

Description

When setting up an email account with thunderbird, we still seem to have a problem with screenreader accessibility.

The tabbing order, is messed up, because when you go to manualy configure your server settings, after you tab past the combo box, for selecting your server settings, for pop or imap, tab one time, and our screenreaders, say incoming protocol

then, we type in pop.gmail.com then if you tab a second time, it still, says incoming protocol

now if you tab a third time, it says incoming port edit, tab again, it says outgoing port

sometimes, it says auto! it needs to read, like this - when you tab past the combo box, to select your choice for servers, such as pop3 and imap, you should tab the second time, and it should say incoming protocol, then I can type in pop.gmail.com then when I tab the third time, it should say, incoming port,

then when I tab the fourth time, it should say outgoing protocol, then I type in smtp.gmail.com for my outgoing server settings! then when I tab the fifth time, it should say outgoing port edit! then I can type in my outgoing port number!

sometimes, my screenreader says incoming port, auto! outgoing port, auto! this needs accessibility improvements, bigtime.

Comment 1

[Magnus Melin [:mkmelin]]

Which version are you using?
(The bug priority field should be left to developers.)

Comment 2

[Bob Edenhofer]

I'm using version 78, witch is the standalone version, it's a 64bit version, not the executable, I'm using the daily build.

Comment 4

[Wayne Mery (:wsmwk)]

Alex, does this affect you as well?

Comment 5

[Alex ARNAUD]

(In reply to Wayne Mery (:wsmwk) from comment #4)

Alex, does this affect you as well?

Yes, it affects me too.

This sounds like a critical problem because you tab to the "down arrow" to open for example the SMTP server and it is presented for a screen reader user exactly the same as the input field. You shouldn't tab to the "down arrow" because on every other list, it is not focusable.

I assume, just adding tabindex="-1" as described here should be sufficient to figure out the problem: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex

Comment 6

[Alex ARNAUD]

I reproduce the issue on latest Daily on Debian GNU/Linux 10, it's why I moved it to all.

As it's a keyboard issue, it could be easily reproduce by tabbing.

Comment 7

[Wayne Mery (:wsmwk)]

Thanks.
It is helpful to have specifics in the bug summary, rather than a generic "problem with ...", so everyone can understand at a glance what the bug is about.

Comment 8

[Alessandro Castellani [:aleca]]

Thanks for the report, I'll take care of it

Comment 9

[Alessandro Castellani [:aleca]]

I assume, just adding tabindex="-1" as described here should be sufficient to figure out the problem

Thanks for the suggestion, I assumed the same but unfortunately is not that easy.
Our implementation of the editable menulist keeps the parent menulist underneath the input field, so that dropdown you see on the right is not a standalone element but the visible part of the menulist.

The focus hits the menulist and the input field separately, and if I set tabindex="-1" to the menulist, the entire element loses the ability to receive a tab focus.
Listening for the focus event on the menulist, in order to move it to the input field, is also not possible as we stuck the user in a loop it can't escape. (Press shift+tab to focus the previous element, the focus moves to the menulist from the input field, the menulist receives the focus event and moves the focus back to the input field).

I think the solution here is to add tabindex="-1" of every menulist item in this grid, and then manually manage the focus via JS.

Comment 10

[Bob Edenhofer]

I am using the standalone version of thunderbird 82.0A, and when I set up my email account, I just clicked the continue button, and it worked, thanks to my blind friend, by the name of Bobby Vinton, he says you no longer half to configure your server settings manualy, however, it would still be an exelent idea, if we resolve this issue, because you never know, when we'll half to configure our server settings, down the road.

Comment 11

[Alessandro Castellani [:aleca]]

This is a deeper problem that affects all the editable menulists as this issue appears also in the calendar event dialog.
I suspect this is a regression introduced during the de-xbl of the editable menulist.
I'll see if I can update the Custom Element to fix all the other areas where it is used, but I'm not completely sure.

Comment 12

[Bob Edenhofer]

I'm not sure, as to what's happening either, I know when I was speaking with Ryan Sypes, who's in charge of development, from the sounds of it, he asked me about testing thunderbird, in witch I'm testing the daily builds, I'll half to get back with him, and I haven't had the time, because I just moved into a new apartment, August 15th, and I've been extremely busy, so I'll ketch up with him, when I can.

Comment 13

[Alessandro Castellani [:aleca]]

I'm not sure how to solve this problem.

• I can't use tabindex="-1" because the menulist is the parent container element of the editable input field, making the child element unfocusable.
• I can't use the aria-hidden attribute as it affects also child elements, and it's wrong to use it on elements that are focusable by nature.
• I can't seem to properly detect and hijack the Tab keyboard navigation in order to skip the focus on the parent menulist.

I have a an itch regarding rebuilding this without extending the menulist since that's the source of our problems.
Any suggestion?

Comment 14

[Thomas D. (:thomas8)]

(In reply to Bob Edenhofer from comment #0)
Hi Bob, I've been asked to comment here to help resolve the issue which you reported.

Sorry, but I'm refusing to try and extract workable steps from your comment 0.

Could you please rewrite your comment 0 according to the structure prescribed for bug reports!
A bug report has three sections:

• Steps to reproduce (a bulleted or numbered list of exact instructions in command form)
• Actual result
• Expected result

Within the sections, certain formatting will be helpful to keep things short and understandable.
Like this:

Steps to reproduce:

• A numbered or bulleted list of instructions in imperative form (click here, select this, toggle that).
• To get bullets, simply add a minus character (-) in front of a line or paragraph, followed by a space. Bugzilla will convert that into bullets.
• To get numbers, simply add 1., 2., etc. in front of a line or paragraph.
• Please mention the exact captions of any buttons, menus etc. which you use, as seen on screen

Actual results

• A bulleted list of the wrong things which actually happened.

Expected results

• A bulleted list of the right things which should have happened.

Bugzilla uses markdown syntax to convert what you have written into HTML formatting. For more information on how to format your comments, please check here:

https://guides.github.com/features/mastering-markdown/

The link is also always shown below the box where you enter your comment, where it says "Markdown styling now supported".

Comment 15

[Alessandro Castellani [:aleca]]

Hey Thomas, I was able to reproduce consistently the issue reported by Bob.
Also, and Bob please correct me if I'm wrong, I think Bob is a blind user using assistive technologies, so I don't think using markdown and formatting the text is a viable option for him.

Comment 16

[Bob Edenhofer]

Thomas? Alessandros correct on that, and I deeply apologize, for the inconvenience, I do use assistive technology, so please be understanding, and work with me, there's other blind indaviduals that are helping with development besides me, so let's work together as a team here, there's no right or wrong here.

Comment 17

[Magnus Melin [:mkmelin]]

No suggestions from me.

Comment 18

[Alex ARNAUD]

(In reply to Thomas D. (:thomas8) from comment #14)

(In reply to Bob Edenhofer from comment #0)
Hi Bob, I've been asked to comment here to help resolve the issue which you reported.

Sorry, but I'm refusing to try and extract workable steps from your comment 0.

Could you please rewrite your comment 0 according to the structure prescribed for bug reports!
A bug report has three sections:

• Steps to reproduce (a bulleted or numbered list of exact instructions in command form)
• Actual result
• Expected result

Hello Thomas, I understand your point of view but you can see whereas Bob cannot. It's quite impossible to describe precisely a situation where you're blind and where there is an issue preventing you to understand the screen you've in front of you. It's like you expect from a blind to describe a picture, it's impossible.

This message is just to help you to understand the situation of blind users. The only one reason I could do better in this area it's because I'm "just" a low-vision person, not blind.

Last but not least, there are a lot of blind people relying on Thunderbird for their daily life and we should take care of them because they are too few able to report issues :).

Comment 19

[Bob Edenhofer]

Hi Alex, you are 100 percent, correct, I agree!

Comment 20

[Wayne Mery (:wsmwk)]

Thomas, do you have advice for comment 13?

Comment 21

[Alessandro Castellani [:aleca]]

The editable menulist will be removed from the account wizard creation in an upcoming daily, and will land in the next ESR.
I'm planning to find better alternatives to this because the editable menulist is an accessibility nightmare and we should nuke it.

Comment 22

[Alessandro Castellani [:aleca]]

The editable menulist has been removed from the new account wizard already available in v90.
Closing this as resolved duplicate of bug 1697575.