The comments correctly pointed out that these elements are largely redundant now – however, as I said, I am not in control of the elements themselves.

So I could have used js to change the elements themselves, however, I thought that was perhaps a bit over the top. I have also had issues with that – accessibility validation tools (like total validator) will tend to read the original source, and can flag up errors on the initial rather than the unmodified code.

I just refined the css itself, from

input:read-only

to

input:read-only:not([type=button]):not([type=submit])

It still seems to me that this is slightly unusual behaviour from firefox, but perhaps it is just me.

Given the html

input {
  color: blue
}

input:read-only {
  color: red
}

input:-moz-read-only {
  color: red
}

<input type="text" value="normal">
<input type="button" value="normal">
<input type="text" readonly="true" value="readonly">
<input type="button" readonly value="readonly">

Firefox (77 and 78 i have tested) shows the elements as:

blue, red, red, red (not-readonly, readonly, readonly, readonly)

Chrome and edgium show:

blue, blue, red, blue (not, not, readonly, not).

Mozilla (https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly) say

Note: Only text controls can be made read-only, since for other controls (such as checkboxes and buttons) there is no useful distinction between being read-only and being disabled, so the readonly attribute does not apply.

Yet, firefox clearly interprets all inputs with a type of button as being readonly (at least for the CSS).

Is this correct? Chrome acts as I would have expected firefox to based on the mozilla page – the readonly attribute, even if applied, is ignored.

I am having a css issue which I dare say I can fix by specifying types in the CSS, but I am not sure if this is a firefox bug, or quirk.