I suspect that 1 is a result of 2 (it's in the tab order between the grid segments input field and the "divide every" radio button, so I fixed that in r25231. Let me know if the text is still not grouped correctly after that and I will see what can be done about it.

Nothing seems to have changed. The radio button is still unreachable, and the label is grouped as before.

Right, not the first time I forget how radio button grouping works... r25240 should hopefully work now. Unfortunately, just like in a few other dialogs, it's not possible to directly intersperse radio buttons with the options belonging to them, so first there is a tab group for the three radio buttons, and after that the input fields corresponding to them. To hopefully make it more obvious, I added suffixes to the input fields so that it's clear what their content represents. Hopefully this works better now. In the future I should probably also check if we can implement radio buttons as labels for input fields or if that just makes things even worse.

Now everything is alright. The radio buttons are nicely grouped, and label order is also fixed.
BTW, the current way of adding accessible suffixes to edit controls does not work with NVDA, that's why I've never noticed them. This is because NVDA seems to completely ignore the accValue property on edit controls, always preferring the actual editable text instead. Narrator reads it as intended though.
Setting accDescription should work everywhere, however object description reporting may need to be manually enabled in some cases.

So would it be best to provide the suffixed value throug both get_accDescription and get_accValue?

Using both will only make Narrator speak the suffixes twice. Further testing shows the following: Narrator reads both, NVDA reports descriptions by default and ignores values, JAWS unfortunately seems to not read anything at all. I hope JAWS does have an option to speak descriptions somewhere, but I don't know where to find it. So, get_accDescription looks a bit better in the end.

Hm, with Narrator get_accDescription doesn't seem to do anything here, that's why I thought that providing both would make sense.

Oops. Narrator indeed ignores it specifically on edit controls. These screen reader things are sometimes way too inconsistent. OK, it makes sense to provide both then.
BTW, since the label order is now right, the suffix on the "grid segments" field is now looking a bit redundant, it's label being the same.
Also, it might be possible to label the second edit field via get_accName.

r25275 now removes the suffix, and adds get_accName to both input fields. It also adds a name to unit dropdown to make it clear what the dropdown changes. This change has also been made to the "Add Silence" dialog since it follows a similar pattern.

Great. The only little oddity I see is that some suffix-less edit fields (e.g., "Grid segments") now have redundant descriptions identical to their contents. It might be better to drop them.

I don't hear that with Narrator. The problem might be that when setting any of the get_acc* properties, the leading text field is no longer read out as a label with Narrator, so I added a custom get_accName to the grid segments field to replace that. I guess that's why you might hear it twice with other screen readers?

BTW, I have also improved input field readouts in the various export dialogs (stream/MIDI/OPL) in r25277-

I don't hear that with Narrator. The problem might be that when setting any of the get_acc* properties, the leading text field is no longer read out as a label with Narrator, so I added a custom get_accName to the grid segments field to replace that. I guess that's why you might hear it twice with other screen readers?

D'oh, there was a stupid bug that required get_accName to be set. You should no longer get those double announcement in r25294.

Double speaking is caused by get_accDescription, not by get_accName. This is why it doesn't happen with Narrator. The problem is that currently get_accDescription calls get_accValue even if there is no suffix.