Editorial: note to expand radiogroup content 'allowances'

This PR attempts to close #1721

Per the discussion we had around the issue, the potential usability and wcag issues this could cause, there were few pros to relaxing how one could create a grouping of radio buttons.  The issue of how would one name such a group if there is no actual "group" container to name was a very good point.  Though HTML allows for such loose grouping of their radio buttons, they do not have a solution for all the potential a11y problems it can solve.

So, this PR takes a different approach to resolving the issue, and instead adds a note to clarify that a radiogroup does not have to be limited to just radio buttons, while ALSO pointing out the potential UX issues of adding other arbitrary/focusable elements.

Maybe something could even be added to overtly state that "hey if you want to group radio buttons like you can in HTML, then use HTML radio buttons!"

Happy to wordsmith this further (examples might be good?)  Or entertain other solutions (we could close the issue as won't fix, but i recall being told we should do _something_ rather than just that).

I created #2158 as a separate issue to resolve, since a lot of the conversation about this concept touched on the topic now logged in that issue.  and I didn't want resolving this issue/pr to lose that separate though related topic.

index.html

@@ -6358,6 +6358,15 @@ <h5>Presentational Role Inheritance</h5>
 			<div class="role-description">
 				<p>A checkable input in a group of elements with the same role, only one of which can be checked at a time.</p>
 				<p>Authors SHOULD ensure that [=elements=] with role <code>radio</code> are explicitly grouped in order to indicate which ones affect the same value. This is achieved by enclosing the radio elements in an element with role <rref>radiogroup</rref>. If it is not possible to make the radio buttons <abbr title="Document Object Model">DOM</abbr> children of the <rref>radiogroup</rref>, authors SHOULD use the <pref>aria-owns</pref> <a>attribute</a> on the <rref>radiogroup</rref> element to indicate the <a>relationship</a> to its children.</p>
+				<div class="note" title="Radiogroups containing other non-radio content">
+					<p>While a <code>radiogroup</code> is primarily meant to group and thus associate related <code>radio</code> buttons, a <code>radiogroup</code> can contain other
+					non-<code>radio</code> button elements. For instance, descriptive text beyond what serves as the radio button's label, or even in some cases, form controls 
+					that are enabled only when a specific radio button has been chosen (checked).</p>
+					<p>However, including non-radio button content into a <code>radiogroup</code> is not without its potential UX drawbacks. As it is generally expected
+					to use arrow keys to navigate between radio buttons, any non-radio button content could go unnoticed by some users, as arrowing through the radio buttons
+					would mean that any other tabbable elements (e.g., hyperlinks or other form fields) would be skipped. When creating a <code>radiogroup</code> with other
+					arbitrary content, consider if the non-radio content could be just as impactful if it was presented as an immediate sibling <em>after</em> the <code>radiogroup</code>.</p>
+				</div>
 			</div>
 			<table class="role-features">
 				<caption>Characteristics:</caption>