The developers of Firefox and Thunderbird have intentionally made their programs accessible. Part of doing so on an ongoing basis is to take the affirmative action of recruiting blind people to test new builds of these programs.  Not doing so is not implementing what is expedcted in terms of making programs properly accessible on an ongoing basis. 

 

If they don’t do this, and if other developers don’t do this who have expressed an interest or willingness to make their programs accessible, such as the developers of Malware Bytes, blind people should contact them and try to get them to do this. 

 

Gene

----- Original Message -----

----- Original Message -----

From: Rob Hudson

Sent: Thursday, April 09, 2020 12:34 PM

To: nvda@nvda.groups.io

Subject: Re: [nvda] Thunderbird talking way too much

 

Brian Vogel <britechguy@...> wrote:
> My point, which seems to have eluded you, is that I constantly see complaints about issues, but when I (or you, or anyone else) bring up the fact that you must report them if you want to have any hope of their being resolved there is generally nothing but the proverbial crickets in response.

This is likely because too many screen reader users have seen the, sorry but I can't duplicate this. Next! Message in response. In addition, there are some larger issues.
Much of the accessibility stack is integrated into the frameworks needed to build the applications; coders of the actual applications built within the framework itself rarely go out of their way to make their appications accessible. That their apps built with the framework are accessible is a happy coincidence. In other words the fact that Firefox and Thunderbird are largely accessible with screen readers is not necessarily due to someone at Mozilla going, hmm, lets open up NVDA/Jaws/whatever and see how this new feature works--although organizations like Mozilla <em>do</em> in fact have some a11y testers. I don't know how many programmers are actually screen reader users there, however. But anyway the accessibility support is there because the coding frameworks they use to construct the applications have basic accessibility built in to them. witness such browsers as Pale Moon, which have this infrastructure removed and which are almost completely unusable with screen readers.
Speaking in general about bug reporting. When you report an issue about an application not working with your screen reader, it is likely you're going to get a, wow, I didn't know about screen readers, response. Because the developers did not know their applications could be used at all by us. Then, you'll either get responses that fall into three categories:
1. Sorry, but I don't know anything about screen readers, so I don't know what to do to fix it. Thank you for your support.
2. Well, let's see if we can make it work. What do I need to do to make this thing work with your ... screen reader?
3. Crickets.
In category one, you're pretty much out of luck. In category two, unless you know about  programming there's not much you can do either. And of course in ccategory three, again, out of luck.
This is a basic summary of why a lot of screen reader users don't report bugs. Yes, doing so may be helpful in a lot of cases, ut in most of them, it can be a futile exercise.

Hi Group,

OK, you can hide the status bar, but then you won't have it readable until you show it again.

On 4/9/2020 12:46 PM, matthew dyer wrote:

Marry,

I just ran into this same problem.  Try this.  Go the view menu and right error to the toolbars and enter on status bar to hide it and this should saulve your problem.  Thanks.

Matthew

On 4/8/2020 2:56 PM, Mary Otten wrote:

Hi all,

I just updated Thunderbird, and all of a sudden, it is talking way too much. For instance, each time I delete a message, I hear about how that message was deleted and added to trash, or some such. There are other announcements as well, rendering the experience entirely too verbose and inefficient for getting through email. I'm using the latest nvda, and as far as I know, there haven't been changes to the mozilla apps enhancements add on which I have been using without incident until now. My t-bird version is 68.7.0; it just updated to that.

Mary

--
They Ask Me If I'm Happy; I say Yes.
They ask: "How Happy are You?"
I Say: "I'm as happy as a stow away chimpanzee on a banana boat!"

You would expect interested blind users to receive alpha and beta releases and send comments.  And if there aren’t, Mozilla should recruit testers.  It is just plain bad procedure not to have releases evaluated by such users as a matter of policy and that is why so many programs such as Malware Bytes, are accessible in one version, have serious accessibility problems in the next, and then are finally fixed in a later release.

 

Gene

----- Original Message [-----

From: Brian Vogel

Sent: Thursday, April 09, 2020 11:57 AM

To: nvda@nvda.groups.io

Subject: Re: [nvda] Thunderbird talking way too much

 

On Thu, Apr 9, 2020 at 12:42 PM, Gene wrote:

My question is why this wasn’t caught by reports from blind people before the release version.

Gene, do you honestly think that there were many, if any, based on what has been seen here and on other screen reader and associated technology groups?

My point, which seems to have eluded you, is that I constantly see complaints about issues, but when I (or you, or anyone else) bring up the fact that you must report them if you want to have any hope of their being resolved there is generally nothing but the proverbial crickets in response.

I have no reason to believe, based on what I have observed on multiple blind technology related groups, that most (and I do mean most, the vast majority most) screen reader users have ever filed a trouble ticket/bug report.  And until or unless they do they should not expect prompt attention to issues that may not even have been recognized.

Each user demographic is and should be responsible for advocating for themselves by reporting the issues they encounter to those who can fix them.  No one else will, or should.
 
--

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

 

 

Yep. Take mee6. The developers basically ,looked at NvDa said, We can't help you" and just ignored every other bug report I submitted. In fact they only give me sigted instructions like 'drag this to that." Yeah, I've seen all of this before.

Sarah Alawami, owner of TFFP. . For more info go to our website.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on [twitch.](http://twitch.tv/ke7zum] Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page YOu will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 9 Apr 2020, at 10:34, Rob Hudson wrote:

Brian Vogel britechguy@... wrote:

My point, which seems to have eluded you, is that I constantly see complaints about issues, but when I (or you, or anyone else) bring up the fact that you must report them if you want to have any hope of their being resolved there is generally nothing but the proverbial crickets in response.

This is likely because too many screen reader users have seen the, sorry but I can't duplicate this. Next! Message in response. In addition, there are some larger issues.
Much of the accessibility stack is integrated into the frameworks needed to build the applications; coders of the actual applications built within the framework itself rarely go out of their way to make their appications accessible. That their apps built with the framework are accessible is a happy coincidence. In other words the fact that Firefox and Thunderbird are largely accessible with screen readers is not necessarily due to someone at Mozilla going, hmm, lets open up NVDA/Jaws/whatever and see how this new feature works--although organizations like Mozilla <em>do</em> in fact have some a11y testers. I don't know how many programmers are actually screen reader users there, however. But anyway the accessibility support is there because the coding frameworks they use to construct the applications have basic accessibility built in to them. witness such browsers as Pale Moon, which have this infrastructure removed and which are almost completely unusable with screen readers.
Speaking in general about bug reporting. When you report an issue about an application not working with your screen reader, it is likely you're going to get a, wow, I didn't know about screen readers, response. Because the developers did not know their applications could be used at all by us. Then, you'll either get responses that fall into three categories:
1. Sorry, but I don't know anything about screen readers, so I don't know what to do to fix it. Thank you for your support.
2. Well, let's see if we can make it work. What do I need to do to make this thing work with your ... screen reader?
3. Crickets.
In category one, you're pretty much out of luck. In category two, unless you know about programming there's not much you can do either. And of course in ccategory three, again, out of luck.
This is a basic summary of why a lot of screen reader users don't report bugs. Yes, doing so may be helpful in a lot of cases, ut in most of them, it can be a futile exercise.

Brian Vogel <britechguy@gmail.com> wrote:

My point, which seems to have eluded you, is that I constantly see complaints about issues, but when I (or you, or anyone else) bring up the fact that you must report them if you want to have any hope of their being resolved there is generally nothing but the proverbial crickets in response.

This is likely because too many screen reader users have seen the, sorry but I can't duplicate this. Next! Message in response. In addition, there are some larger issues.
Much of the accessibility stack is integrated into the frameworks needed to build the applications; coders of the actual applications built within the framework itself rarely go out of their way to make their appications accessible. That their apps built with the framework are accessible is a happy coincidence. In other words the fact that Firefox and Thunderbird are largely accessible with screen readers is not necessarily due to someone at Mozilla going, hmm, lets open up NVDA/Jaws/whatever and see how this new feature works--although organizations like Mozilla <em>do</em> in fact have some a11y testers. I don't know how many programmers are actually screen reader users there, however. But anyway the accessibility support is there because the coding frameworks they use to construct the applications have basic accessibility built in to them. witness such browsers as Pale Moon, which have this infrastructure removed and which are almost completely unusable with screen readers.
Speaking in general about bug reporting. When you report an issue about an application not working with your screen reader, it is likely you're going to get a, wow, I didn't know about screen readers, response. Because the developers did not know their applications could be used at all by us. Then, you'll either get responses that fall into three categories:
1. Sorry, but I don't know anything about screen readers, so I don't know what to do to fix it. Thank you for your support.
2. Well, let's see if we can make it work. What do I need to do to make this thing work with your ... screen reader?
3. Crickets.
In category one, you're pretty much out of luck. In category two, unless you know about programming there's not much you can do either. And of course in ccategory three, again, out of luck.
This is a basic summary of why a lot of screen reader users don't report bugs. Yes, doing so may be helpful in a lot of cases, ut in most of them, it can be a futile exercise.


.

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

Sent: Thursday, April 09, 2020 9:38 AM

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

 

 

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

 

 

Yes, turning off the status bar fixed it completely!
Thanks much!
Roger









On 4/8/2020 5:34 PM, David Csercsics wrote:

I got the 68.7 update today and noticed it was chatty. It was reading the status bar, so I disabled that, and it's less verbose. You can disable the status bar from view -> toolbars.





.

.

i think it was Mike who suggested turning off the status bar.  i did this and it worked fine.  it works for me like it used to before i upgraded.

On 4/9/2020 3:44 PM, Ron Canazzi wrote:

Hi Group,

Well, I also am seeing the latest version of Thunderbird talking way too much.  For about two years, the updates past version 60.8 did not read the status line properly.  Now with 68.7, the status line has returned, but it seems that every action that you perform that causes a change to the status line is now vocalized.  This is entirely too much verbiage. A clumsy work around is to perform an action and then quickly invoke the read line function with insert + up arrow and then go on to perform a new action.  This works best for doing a filtered delete.  By this I mean that I have messages filtered into folders and grouped by conversation.  When doing a browse and delete in each folder, after I select with standard shift + up/down arrows and want to move on for a mass deletion, rather than waiting for the status line to read out, I do the selection, then press the read line keystroke and then continue the shift + down arrow keystroke to continue to highlight the messages I want to delete. It's clumsy but once you get used to it, it does work.

Since this install allows me to stay current with security issues in Thunderbird, I think I'll keep the 68.7 version.  I like being current and having the status line read in some form. Maybe they'll tweak the program a little more for accessibility in future updates.

This is the time when a JAWS frame type feature would be good. You could create the frame around the status line and make it silent and only readable with the hotkey.


On 4/9/2020 9:57 AM, matthew dyer wrote:

Hi,


Getting the same thing.  Hope they can find a fix for this. Thanks.


Matthew



On 4/8/2020 5:44 PM, Roger Stewart wrote:

I just upgraded Thunderbird to the latest version.  I'm getting a lot of unwanted feedback telling me every time I delete a message how many messages have been moved to trash and how many unread messages are in the inbox.  I hope a fix can be found to turn this off. Maybe someone might find it useful, and if this is so, then a toggle to turn it on or off would be good.


Roger

Brian Vogel <britechguy@gmail.com> wrote:

My point, which seems to have eluded you, is that I constantly see complaints about issues, but when I (or you, or anyone else) bring up the fact that you must report them if you want to have any hope of their being resolved there is generally nothing but the proverbial crickets in response.

This is likely because too many screen reader users have seen the, sorry but I can't duplicate this. Next! Message in response. In addition, there are some larger issues.
Much of the accessibility stack is integrated into the frameworks needed to build the applications; coders of the actual applications built within the framework itself rarely go out of their way to make their appications accessible. That their apps built with the framework are accessible is a happy coincidence. In other words the fact that Firefox and Thunderbird are largely accessible with screen readers is not necessarily due to someone at Mozilla going, hmm, lets open up NVDA/Jaws/whatever and see how this new feature works--although organizations like Mozilla <em>do</em> in fact have some a11y testers. I don't know how many programmers are actually screen reader users there, however. But anyway the accessibility support is there because the coding frameworks they use to construct the applications have basic accessibility built in to them. witness such browsers as Pale Moon, which have this infrastructure removed and which are almost completely unusable with screen readers.
Speaking in general about bug reporting. When you report an issue about an application not working with your screen reader, it is likely you're going to get a, wow, I didn't know about screen readers, response. Because the developers did not know their applications could be used at all by us. Then, you'll either get responses that fall into three categories:
1. Sorry, but I don't know anything about screen readers, so I don't know what to do to fix it. Thank you for your support.
2. Well, let's see if we can make it work. What do I need to do to make this thing work with your ... screen reader?
3. Crickets.
In category one, you're pretty much out of luck. In category two, unless you know about programming there's not much you can do either. And of course in ccategory three, again, out of luck.
This is a basic summary of why a lot of screen reader users don't report bugs. Yes, doing so may be helpful in a lot of cases, ut in most of them, it can be a futile exercise.