Fix/form toggle accessibility

[youknowriad]

This PR closes #906 by:

• Adding an optional "On/Off" Toggle to the FormToggle component
• Transforming the FormToggle component to an inline component
• Dropping the embedded label from the FormToggle component
• Explicitly use id/for for the input/label of the "Pending review" toggle.

[aduth]

Per #906, it seemed the recommendation would be to disable this from being read by screen readers, I presume because the input's own value state would suffice.

For this reasons, our decision was to keep using visible "on" and "off" text, hidden to assistive technologies with aria-hidden="true" because the state change is already announced by screen readers.

Also discussing the hint more generally at #906 (comment)

[aduth]

Should we need to suffix this or manipulate it in any way, or can we treat it as verbatim presumed unique from the parent passing the prop?

[youknowriad]

I think we should treat it as unique from the parent to allow its usage for the label htmlFor without the need to "know" the prefix.

[aduth]

Ohhh, I missed that this was assigning the default. But why do we need a default? If the parent component isn't passing an ID, what purpose does the ID have?

[youknowriad]

You're right. It's probably safe to delete.

[aduth]

Can you explain the need for z-index? Does it need to be higher than a dialog?

[youknowriad]

yes, this is a trick to allows the onChange handler to trigger when we click on the invisible input.

[youknowriad]

Oh Higher than the dialog probably not. I'm updating

[aduth]

I'm wondering if some logical groupings in the _z-index.scss, even just a few comments, could help avoid this temptation of assigning it a value a little more than the next highest. Like "Relative Siblings", "Layout", "Dialogs", etc. We have some grouping already, but mostly by related components. Dunno if that's a more sustainable pattern than lower-to-highest. It's a difficult problem, and one which I don't think needs to be solved here, but I expect will continue to surface over time.

Related discussion at #637

[youknowriad]

Yes, I like the idea of grouping by "type" and inside the lowest type "relative siblings" group by related components.

[aduth]

It's not a terribly complex pattern, but unfortunate in how it forces a class component. What do you think about a higher-order component for convenience?

function MyComponent( { id } ) {
	return <div id={ id } />;
}

export default withUniqueId( 'prefix-' )( MyComponent );

Not to be solved here.

[youknowriad]

Funny, because I was thinking the exact same thing 👍 (maybe uid is better as prop or uniqueId)

[aduth]

(maybe uid is better as prop or uniqueId)

I don't feel strongly that it's necessary, but between the two I might prefer uniqueId just for clarity by verbosity.

[aduth]

I like the idea of treating these components as inputs and leaving it to the developer to create the associated label. Or at least I think this helps avoid the sorts of issues observed in #906. We should start to look at how to document components as such. Code-wise I think this looks good. Still curious to see where #906's discussion goes, but with current usage not making use of the hint, I think it can be reevaluated later (or dropped now and introduced later? Not really sure its value if we choose not to use it).