Thanks for raising this, @gavinwye.
@adamsilver raised a good point about this pattern in Slack - when Javascript is not available the revealed thing that relates to Yes, for example, will be under No and out of context, and if there鈥檚 something to reveal for both Yes and No then similar problems arise.
This appears to be an issue with the current implementation in Elements - with Javascript enabled, the fields are associated with the radios because only one is visible at a time:

Whereas without Javascript, both revealed fields are visible at the same time and there is nothing to associate each field with the corresponding radio.

One suggestion is that we could somehow make it so that the 'inline' modifier is not applied when javascript is not available and there is conditionally revealing content, meaning that 'Yes' and 'No' would appear stacked with the revealed content underneath each radio button.
Thanks for spotting this @gavinwye - we'll investigate to see what we can do to improve the layout of that use case.
In the meantime we'd recommend either not using the inline layout in combination with conditionally revealed content or moving the conditional content onto another screen. For the reason @adamsilver gave, these might be preferable approaches anyway.
Perhaps there could be some guidance to say don't use conditionals with inline radios.
Another little thing that we might want to consider is that if you select NO, the left border lines up with YES.
We have an interesting use case. The service I'm working on is for staff. As we all know, staff hate waiting for anything to load as rubbish equipment and network latency already slow everything down. So we use conditional reveals in a few places rather than loading different views.
However, if we implemented the question stacked the whole design no longer works. The way the component is built always jams the revealed content into the dom after its selector pushing the remaining inline buttons down. (see screenshot).
So the recommendation of not using conditional reveals on inline-radios is fine when it's one field. But if it's a collection of fields it pushes the remaining radios to the bottom where they lose context.
It would be good if you could position the hidden fields in the dom manually and then pass the ID into the radio component to tell it to reveal, rather than dictating the DOM order with the component.

Hi @gavinwye, @abbott567 and @adamsilver
We spent some time looking at this, can I point you in the direction of my comment here https://github.com/alphagov/govuk-frontend/pull/970#issuecomment-422759580 which explains why we haven't directly addressed this issue.
Hi all, with #970 our recommendation is not to use conditional revealing content with inline radios, so we're forcing them to be display:block when combined, which in turn resolves issue described here.
I'll close this issue for now.
Most helpful comment
We have an interesting use case. The service I'm working on is for staff. As we all know, staff hate waiting for anything to load as rubbish equipment and network latency already slow everything down. So we use conditional reveals in a few places rather than loading different views.
However, if we implemented the question stacked the whole design no longer works. The way the component is built always jams the revealed content into the dom after its selector pushing the remaining inline buttons down. (see screenshot).
So the recommendation of not using conditional reveals on inline-radios is fine when it's one field. But if it's a collection of fields it pushes the remaining radios to the bottom where they lose context.
It would be good if you could position the hidden fields in the dom manually and then pass the ID into the radio component to tell it to reveal, rather than dictating the DOM order with the component.