Now the browser can make out a connection between the checkbox and the following text.With this simple step we’ve achieved two things: By doing so, we don’t just write “Mushrooms” but tell the browser that this is the label FOR our “pizza-topping1” ID. We identify the checkbox by giving it an ID. Besides, it would be nice to be able to click on “Mushrooms” to activate (or deactivate) the checkbox, too. But what about people with motor impairments? The checkbox may be too small for them to click on. The negative side effect here is that you can only click on the checkbox to change its state. The browser doesn’t see any connection between these two elements. In this example we have an input of type checkbox followed by the text “Mushrooms”.

To help you understand what’s wrong, we’ll then listen to a screen reader.

In this case we’ll start with very simple (and wrong) markup and then we’ll enhance it more and more. And most of the time a browser is a simple piece of software that really just reads and doesn’t understand what it’s doing. Bear in mind that a browser interprets the markup by reading from top to bottom. Developers may addt to the page canvas every element they see in the designs “as is” without thinking of their meanings. If they had the same id value, then you would have a problem (how it would manifest in a screen reader depends on things and stuff).Something I often see is an incorrect setup of forms. The fact that they have the same name value is no problem.

When I access the field in NVDA, all it says is 'checkbox checked'. Right off the bat there is a problem here because the is not associated with the control, and the visible text that is next to the checkbox is not associated with the field. Given the example you cite in your comment, it returns this code:

Checkbox accessibility screen reader