The short answer
Simply use labels.
The long answer
If you are to design anything based on future possibilities, you will never finish a design, because possibilities are endless.
There are basically 3 design approaches (UX or software):
- Throwaway (revolutionary)
- When you have little understanding of the problem (high level of uncertainty)
- You design quick, test quick, and mainly to learn what works and what not.
- Normally a quick process, but designs are likely to be discarded (leading to redesigns or rework).
- When you have some or fair understanding of the problem/requirements, but it is incomplete and you suspect new requirements will be added.
- You build the design step-by-step, accounting for new knowledge in each iteration.
- Designs typically serve as basis for next iteration.
- The danger is that bad designs may persist.
- When you have clear understanding of the problem and requirements.
- You design to meet all requirements.
- This process can be long.
When you say 'there is a possibility', it seems you are uncertain, which means a throwaway approach is probably the way to go.
What's more, if your design is based on a requirement that isn't quite really needed just yet, you may provide an odd solution that isn't tailored to what the users really need.
I suspect that this is exactly what's happening here - to convey yes or no to users, simply use labels; why provide a (disabled) control? This makes no sense from usability point of view (users might think: Why can't I interact with this control? Why is it always disabled?).
When you do need a control (something the users can interact with), iterate the design.