+1 for the radio button representation.
For the best accessibility, I’d have used a radio-button set, which contains inputs that are semantically-hidden as long as they are disabled. When the radio button choice changes, make sure the user is notified of the change in the page content (aria-live would probably work well somewhere in there).
Thinking notes on disabled inputs
A disabled control is always a bit difficult to explain. With a quick reflexion, here’s how I’d explain it:
A disabled input is an input. An input expects the user to interact with it to convey some information (here, a string of text). But it’s disabled, so actually we don’t expect the user of interacting in any way with it. Okay, then what is its purpose? We want to show that some kind of action might be asked of the user given they fulfill the right conditions to activate the field. What is the condition? In our example, it’s that all other fields are unselected. It’s exactly the kind of semantics the radio buttons can provide. Does the user need to know that there’s an input waiting to be activated? Not really, the input being completely hidden as long as the option is not selected would work about as good. So the semantics of the hidden input are not needed when the option is not selected and we can hide it from screen readers without creating a noticeable accessibility issue (technically it is a very minor one since the visuals and semantics are not perfectly aligned).