Make the Installer for Umami as accessible a possible

This is a follow up issue to #2938185: When installing Umami, only show warning if 'Demo Umami' radio button is selected (and ensure that it is obvious that warning message only applies to the Umami profile)

Let's make the installer as accessible as possible.

(Update: andrewmacpherson 11th September 2018):
I do still have some ideas to improve this. Quick brain dump follows...

Currently: The warning is nested inside the #description as a span, which uses the states system to control visibility (which results in display:none).
Problem: it isn't used in the accessible display description reliably. It seems that updating form descriptions dynamically, the new message doesn't get properly conveyed to assistive tech.
Ideas:
1. use visually-hidden on the span nested inside the #description. (Does the States API have that?) Then the waring would be part of the accessible description computation at all times, regardless of visibility.
2. If states API can't do it, can we use a selector in the stylesheet to do put equivalent styles on it?
2a: using the :checked pseudo class, to control visibility of the nested span
2b: using :focus-within on the .form-item wrapper div
3. A custom JS behaviour for the installer form could toggle the visually-hidden class instead.
4. another idea would be to take it out of the #description, and give it an ID of it's own. Then fudge the form so the Umami radio was aria-describedby two elements. States API (display:none) wouldn't be a problem then, because aria-describedby can work with display:none, if it is on the same element with the targeted ID ref. The reason it doesn't work at the moment is that the description ID and display:none are on different elements.

Background, things we already tried:
We tried various arrangements of aria live roles. The results were very flaky, some screen readers announced it immediately, some didn't. In some cases the warning it couldn't be found at all. Eventually we went for States API, and said we'd do accessibility in a follow-up. It's still worth fixing, but it's fallen down my priority list.
We didn't try all of my suggestions before finishing the other issue (it was a bit big, and screen readers were only one aspect, so I agreed to address it in a follow-up. That's good, because it's going to be easier to test on it's own, without other stuff happening in the same patch.
My old testing notes may no longer apply, I need to do a new round of that. The previous solutions and testing notes are probably hard to understand unless you have knowledge of different screen readers, and ARIA implementations. The flakiness was rooted deep in the way aria-live works. Other approaches involved a exploiting a (spec-compliant) quirk of the way that aria-describedby works, but were hard. So we went for a simple use of States API.