This problem raises serious questions about how accessibility is implemented as Thunderbird is developed.
This is just the kind of thing you would expect to see implemented if a sighted person or persons, who know nothing about proper implementation of accessibility, add or design accessibility functions.  Just because something talks doesn't mean it is practical or properly usable.
How did such a function get past beta testing or even alpha testing?  Unless Thunderbird changes how it evaluates accessibility changes or new implementations, there will be a constant threat of future versions presenting new and completely unnecessary accessibility problems.  I would suggest those who use the program contact the developers about this problem.
Gene
----- Original Message -----
*From:* Brian Vogel <mailto:britechguy@gmail.com>
*Sent:* Thursday, April 09, 2020 9:38 AM
*To:* nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
*Subject:* Re: [nvda] Thunderbird talking way too much
My guess is that the good folks at Thunderbird had gotten complaints that it was impossible to know, for instance, whether all new e-mail had completed downloading when you fired up T-bird at the start of the day, and decided to expose a lot more information presented on the status bar to the screen reader.

What they probably hadn't counted on is the fact that a screen reader will detect changes and read them as they're detected, and that's really, really irritating if you're reading your e-mail messages and status stuff just barges in while doing so.

If they have sighted folks doing testing for these new functions, it wouldn't surprise me if they just sat there when the status bar was really active watching to see that it was being reported correctly, never moving along like one normally would into reading messages.  And I can get that, as even though I have the status bar displayed, I virtually never look at it at all.  The occasional glance occurs, but I wouldn't really miss it at all if it weren't there by default.

It's well-nigh impossible for most of us who see to have any real idea of exactly how screen reader users typically approach using various pieces of software (and I include myself, though I do have at least some idea at this point). And there will never be enough in-house actual screen reader users doing accessibility testing.  That's one of the reasons I push so hard to get folks who encounter accessibility issues to file bug/issue/trouble reports with the companies that produce the software.  You all are able to give a far more accurate description of what the software is doing that you don't want with the screen reader as well as what the preferred behavior would be.  Also, given your years of end-user experience, you're often in a far better position to know whether the issue you're having is with the screen reader or due to a change in the software you're using the screen reader to access, and that's often the key to getting to the root of the problem as well as the fix.

--

Brian *-*Windows 10 Pro, 64-Bit, Version 1909, Build 18363

*Power is being told you're not loved and not being destroyed by it.*

       ~ Madonna