[accessibility] Webform toggle element is deprecated

Problem/Motivation

The toggle element provided by webform is a custom UI element, and the current implementation is inaccessible.

• Sighted keyboard users cannot focus the toggle switch to operate it (likewise screen readers).
• Even if they were focusable, the semantics are wrong. The current implementation is combination of a hidden checkbox (not passed to OS accessibility API) and cosmetic DIVs with no machine readable semantics. Screenreader users may well be unaware that the toggle elements exist at all.

Proposed resolution

• Devise a new markup/JS pattern, aim to follow practices in WAI-ARIA and ARIA Authoring Practices. Can we use a simple <button> with aria-pressed, instead of managing cosmetic DIVs and a hidden checkbox in parallel?
• Rework Drupal.behaviors.webformToggle JS and WebformToggle::preRenderCheckbox() as appropriate.
• Note 1: the webform element "title" setting should end up being the computed accessible name for the button.
• Note 2: there are single and multiple versions of this element available. Using the "toggles" version already wraps them up together with fieldset/legend elements, and uses aria-describedby to associate the "description" setting with the fieldset. In other words, this already works like radios and checkboxes, so doesn't need fixing here. Confirm it still works though...
• Note 3: The webform "description" should be associated with single-toggle elements using aria-describedby directly on the button element itself.
• Note 4: the forthcoming ARIA 1.1 (candidate recommendation currently) introduces a new "switch" role, which aims to get around the semantic debate of whether to use a button or a checkbox role for these things. It looks ideal, however it's brand new and we should avoid using this until we know it has good support across many browser/AT combinations. For now, <button aria-pressed="true"> is a more reliable pattern.
• Question 1: how do we convey the custom toggle-off and toggle-on text (which appear inside the switch background? These are not the same as the <label>. Do we assume they are cosmetic, or should we include a Drupal.announce(), or something else? Discuss :-)
• Question 2: do we need to update the way WebformToggles render element PHP class works? It seems to work by changing the render type of it's children. Fingers crossed we might not need to touch this one.

Remaining tasks

• Manual testing is essential! Keyboard-only, and a variety of screen readers.
• Functional javascript tests are possible, triggering keyboard events on the toggle button. Assert (e.g.) that the toggle-off text has gone, and the toggle-on text has appeared, or just test for expected class attribute values.

User interface changes

No visual changes are needed. This is all about keyboard operation, and conveying dynamic state semantics to assistive technology.

API changes

None.

Data model changes

None.