This support ticket is created 7 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I tested the readonly parameter for radio inputs, and you are correct, it is being ignored.
I did wonder if that was by design on CRED forms to publish posts (where there is no prior value) but it fails on CRED edit forms, too.
As you probably know new versions of Toolset plugins, including CRED, are currently undergoing testing ahead of an expected release in the coming days, so I'm going to set up a test site with these development versions to see if the issue persists before escalating this thread.
I'm reviewing the escalated threads now that the new releases are out.
Regarding readonly not being applied to the radio fields, the reason is that readonly only works with text fields.
If you try to manually add a text field to a CRED form you are presented with the additional options (such as readonly), as you can see in the screenshot, but adding other field types you are not presented with the same.
I've made a note to update our documentation to make that clear.
That page includes a list of which fields can have custom classes added.
It's basically simple fields such as text inputs.
Complex fields such as radio inputs add not just an input field but an HTML structure around it, and it's not clear exactly where a custom class would be added.
You can always add a custom class on a container element and construct the CSS selector as required to target the specific element required (e.g. the label, the input field).