aria-controls spec update

resolves #995 

The intent with this update is, 4 years later, to propose a draft solution for the issue I opened.

With the progress made on aria-details, and the overlaps in how this attribute could have been useful, I did take great liberty in pulling in further explanation/examples for aria-controls from the existing aria-details spec text.

Things i didn't overly call out in this pr, but should probably make their way in there concern recommendations on whether or not to expose the controlling relationship depending on DOM/a11y API relationship.  E.g., we probably don't need an explicit user exposed controlling relationship if a controlled element is directly after the controlling element in the dom (e.g., a disclosure widget) but we _would_ want AT to know they could make this association clear if the elements were located in different portions of the a11y tree - e.g., a button opening a non-modal dialog that happens to be at the bottom of the DOM, but the button is somewhere else entirely.

index.html

@@ -11175,13 +11175,17 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 		<div class="property" id="aria-controls">
 			<pdef>aria-controls</pdef>
 			<div class="property-description">
-				<p><a>Identifies</a> the <a>element</a> (or elements) whose contents or presence are controlled by the current element. See related <pref>aria-owns</pref>.</p>
-				<p>For example:</p>
+				<p><a>Identifies</a> the <a>element</a> (or elements) whose contents or presence are controlled by the current element or composite widget. See related <pref>aria-details</pref>.</p>
+				<p>The <code>aria-controls</code> property is for referencing elements which are modified through user interaction of the current element or composite widget the user is interacting with. The presense of <code>aria-controls</code> enables <a>assistive technologies</a> to make users aware of the current element's association with the controlled elements, or that an association exists for instances where the controlled element was previously in the hidden state, but through user interaction of the controlling element, the associated element has become accessible.</p>
+				<p>Instance where an <code>aria-controls</code> association could be made:</p>
 				<ul>
-					<li>A table of contents tree view can control the content of a neighboring document pane.</li>
+					<li>A tree view representing a table of contents where choosing a treeitem updates content of a neighboring document pane.</li>
 					<li>A group of checkboxes can control what commodity prices are tracked live in a table or graph.</li>
 					<li>A tab controls the display of its associated tab panel.</li>
+					<li>A radio button group applies filter choices to a listing of search results.</li>
 				</ul>
+				<p>
+				<p>Additionally, the <code>aria-controls</code> property supports referring to multiple elements. For example, a button is pressed to highlight different instances of spelling errors in a document. A user agent MAY expose to a user that there are X number of controlled elements and allow for a mechanism to cylcle through those elements, and returning to the controlling element when the user chooses to do so.</p>
 			</div>
 			<table class="property-features">
 				<caption>Characteristics:</caption>