Hi, and thanks for the article

One thing maybe off topic but I'd like to ask. If I see misspell in NVDA's documentations or interface, and I just a translater, should I fix, and submit pull request, or I should report it in NVDA translation mailing list for other people in NVDA developer to fix it? Right now I'm a translater, and I could contribute that way if I see any.

Appreciated your help.
Cuong

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

• For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

• Some of the things I wrote are rough at times (my apologies for these).
• The biggest takeaway is that coding is not for everyone.
• Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

• Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
• I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
• I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

• You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
• You are writing an essay. After all, coding is responding to an essay prompt (or two).
• You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
• Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
• You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

• Email: seantolstoyevski@...
• GitHub: SeanTolstoyevski

👨‍🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

• For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

• Some of the things I wrote are rough at times (my apologies for these).
• The biggest takeaway is that coding is not for everyone.
• Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

• Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
• I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
• I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

• You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
• You are writing an essay. After all, coding is responding to an essay prompt (or two).
• You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
• Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
• You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

• Email: seantolstoyevski@...
• GitHub: SeanTolstoyevski

👨‍🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.

Just press NVDA spacebar again, Hettie. A lower beep tone is what you
want to hear.

So I suspect I'm gonna get in trouble for saying this, but I'm just
sharing my experience. Sometimes, it appears like NVDA has trouble
activating some web elements, & I often have to use a variety of
techniques if enter or spacebar doesn't work, including the NVDA f7
key, using object navigation, NVDA backspace/shift backspace to ensure
the element is in focus & then enter/spacebar/click, etc. I think some
of it just has to do w/the element not actually being in focus,
although NVDA indicates that it is.

On 8/1/20, Hettie <woehler.hettie@gmail.com> wrote:

Hi all

I used the NVDA key + spacebar to activate an unsubscribe button on my
AVG account web page. I was able to tab to the wanted button but unable
to activate it. After this it was also not possible to read the screen
with the arrow keys. When my son came to assist me he saw that there was
a message on the screen asking whether I really want to unsubscribe.
That message wasn't read to me and as I douldn't navigate the screen I
didn't knew that I was supposed to react on a yes/no question.

How do I return to the normal screen after pressing the NVDA key +
spacebar?


Thanks for any help.


Hettie



--
This email has been checked for viruses by AVG.
https://www.avg.com

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

• Some of the things I wrote are rough at times (my apologies for these).
• The biggest takeaway is that coding is not for everyone.
• Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

• Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
• I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
• I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

• You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
• You are writing an essay. After all, coding is responding to an essay prompt (or two).
• You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
• Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
• You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

Hi all

I used the NVDA key + spacebar to activate an unsubscribe button on my
AVG account web page. I was able to tab to the wanted button but unable
to activate it. After this it was also not possible to read the screen
with the arrow keys. When my son came to assist me he saw that there was
a message on the screen asking whether I really want to unsubscribe.
That message wasn't read to me and as I douldn't navigate the screen I
didn't knew that I was supposed to react on a yes/no question.

How do I return to the normal screen after pressing the NVDA key +
spacebar?


Thanks for any help.


Hettie



--
This email has been checked for viruses by AVG.
https://www.avg.com

From: nvda@nvda.groups.io [mailto:nvda@nvda.groups.io] On Behalf Of Quentin Christensen
Sent: Friday, 31 July 2020 06:07
To: nvda@nvda.groups.io
Subject: Re: [nvda] NVDA PROBLEM

--

Which software do you refer to?
If you're talking about adobe reader or adobe digital editions, yes, you
can read the toc.

Em sáb., 1 de ago. de 2020 às 04:59, Aschalew Byness <
gakidan.ashagre235@gmail.com> escreveu:

Hi you lovely guys
I couldn’t read table of contents with NVDA. Whenever I try to read
table of contents, nvda reads: out of link TOC \o "1-3" \h \z \u
link .
My sighted friends read the full content of the TOC. Nvda skips it
this way. ‘out of link TOC \o "1-3" \h \z \u link .

Solution?

--
Daniel Damacena

Hi you lovely guys
I couldn’t read table of contents with NVDA. Whenever I try to read
table of contents, nvda reads: out of link  TOC \o "1-3" \h \z \u
link   .
My sighted friends read the full content of the TOC. Nvda skips it
this way. ‘out of link  TOC \o "1-3" \h \z \u   link   .

Solution?

Sorry to clutter the list but I wanted to thank David and Sarah for helping me so much. I did not have the website that sarah mentioned written down before and when I went in that way it worked. I have memory problems now and thus the reason my confidence level is even lower. Thank you both for helping me have the courage to try downloading it this way.
Thank you to those who designed the website that the link said exactly what told me that I was at the correct spot to download the latest update.
On 7/30/2020 3:59 PM, Sarah k Alawami wrote:

You will be fine. Go to nvda-project.org and use yoru screen reader's find function to find and navigate. You will be fine. You won't get hurt.

--

Sarah Alawami, owner of TFFP. . For more info go to our website. <http://www.tffppodcast.com>

Check out my adventures with a shadow machine. <http://tffppodcast.com/shadow>

to subscribe to the feed click here <http://feeds.feedburner.com/tffp> and you can also follow us on twitter <http://twitter.com/tffppodcast>

Our discord <http://discord.tffppodcast.com> 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 <http://lbry.tv/@ke7zum> and my tffp lbry page <http://lbry.tv/@tffppodcast> 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 <Http://patreon.com/tffppodcast>

On 30 Jul 2020, at 12:25, Betsy Grenevitch wrote:

Thank you. I am waiting to hear back from David hopefully with a
link to the full install. As I have told you and now told him I do
not feel comfortable with websites where I have to download
something unless there is a direct link. I know it is a fear I
need to get over but I guess it is because of a lack of training
on computers.


On 7/30/2020 11:39 AM, Brian Vogel wrote:

And to add to Mr. Goldfield's advice, if you have an issue
running the full installer for NVDA 2020.2, then manually
uninstall whatever NVDA you currently have installed via Control
Panel, Programs and Features, then trying to install the latest
again.  But don't do that first, as an install-over install
generally works just fine.
--

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

*/Science has become just another voice in the room; it has lost
its platform.  Now, you simply declare your own truth./*

~ Dr. Paul A. Offit, in /New York Times/ article, /How
Anti-Vaccine Sentiment Took Hold in the United States/
<https://www.nytimes.com/2019/09/23/health/anti-vaccination-movement-us.html>/,/September
23, 2019

--
Betsy Grenevitch
678-862-3876

--
Betsy Grenevitch
678-862-3876