Tidying up section "Characteristics of Roles"

index.html

@@ -565,10 +565,6 @@ <h2>Characteristics of Roles</h2>
 		<p>Roles define the following characteristics. </p>
 		<section id="isAbstract">
 			<h3>Abstract Roles</h3>
-			<dl class="runin">
-					<dt>Values</dt>
-					<dd>Boolean</dd>
-				</dl>
 			<p>Abstract <a>roles</a> are the foundation upon which all other <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles are built. Content authors MUST NOT use abstract roles because they are not implemented in the <abbr title="application programing interface">API</abbr> binding. User agents MUST NOT map abstract roles to the standard role mechanism of the accessibility API. Abstract roles are provided to help with the following:</p>
 			<ol>
 				<li>Organize the Roles Model and provide roles with a meaning in the context of known concepts.</li>
@@ -611,29 +607,14 @@ <h3>Required Context Role</h3>
 			<p class="note">An element with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> fulfills this requirement.</p>
 		</section>
 		<section id="namecalculation">
-			<h3>Accessible Name Calculation</h3>
-			<dl class="runin">
-				<dt>Values</dt>
-				<dd>One of the following values:
-					<ol>
-						<li>author: name comes from values provided by the author in explicit markup features such as the <pref>aria-label</pref> attribute, the <pref>aria-labelledby</pref> attribute, or the host language labeling mechanism, such as the <code>alt</code> or <code>title</code> attributes in <abbr title="Hypertext Markup Language">HTML</abbr>, with HTML <code>title</code> attribute having the lowest precedence for specifying a text alternative.</li>
-						<li>contents: name comes from the text value of the <a>element</a> node. Although this may be allowed in addition to "author" in some <a>roles</a>, this is used in content only if higher priority "author" features are not provided. Priority is defined by the <a href="#mapping_additional_nd_te" class="accname">accessible name and description computation</a> algorithm [[ACCNAME-1.2]].</li>
-            <li>prohibited: the element does not support name from author. Authors MUST NOT use the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attributes to name the element.</li>
-					</ol>
-				</dd>
-			</dl>
-			<section id="namecomputation">
-				<h4>Name Computation</h4>
-				<p><a href="#mapping_additional_nd_name" class="accname">Name Computation</a> is defined in the Accessible Name and Description specification.</p>
-			</section>
-			<section id="descriptioncomputation">
-				<h4>Description Computation</h4>
-				<p><a href="#mapping_additional_nd_description" class="accname">Description Computation</a> is defined in the Accessible Name and Description specification.</p>
-			</section>
-			<section id="textalternativecomputation">
-				<h4>Accessible Name and Description Computation</h4>
-				<p><a href="#mapping_additional_nd_te" class="accname">Accessible Name and Description Computation</a> is defined in the Accessible Name and Description specification.</p>
-			</section>
+			<h3>Name From</h3>
+			<p>Determines which content contributes to the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]].</p>
+			<p>One of the following values:</p>
+			<ol>
+				<li>author: name comes from values provided by the author in explicit markup features such as the <pref>aria-label</pref> attribute, the <pref>aria-labelledby</pref> attribute, or the host language labeling mechanism, such as the <code>alt</code> or <code>title</code> attributes in <abbr title="Hypertext Markup Language">HTML</abbr>, with HTML <code>title</code> attribute having the lowest precedence for specifying a text alternative.</li>
+				<li>contents: name comes from the text value of the <a>element</a> node. Although this may be allowed in addition to "author" in some <a>roles</a>, this is used in content only if higher priority "author" features are not provided. Priority is defined by the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]].</li>
+				<li>prohibited: the element does not support name from author. Authors MUST NOT use the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attributes to name the element.</li>
+			</ol>
             <section id="namefromauthor">
                 <h4>Roles Supporting Name from Author</h4>
                 <div id="index_fromauthor">
@@ -651,14 +632,8 @@ <h4>Roles which cannot be named (Name prohibited)</h4>
             </section>
 		</section>
 		<section id="childrenArePresentational">
-			<h3>Presentational Children</h3>
-			<dl class="runin">
-				<dt>Values</dt>
-				<dd>
-					<p>Boolean (<code>true</code> | <code>false</code>)</p>
-				</dd>
-			</dl>
-			<p>The <abbr title="Document Object Model">DOM</abbr> descendants are presentational. [=user agents=] SHOULD NOT expose descendants of this <a>element</a> through the platform <a>accessibility <abbr title="Application Programing Interface">API</abbr></a>. If [=user agents=] do not hide the descendant nodes, some information may be read twice.</p>
+			<h3>Children Presentational</h3>
+			<p>Indicates whether DOM descendants are presentational. <a>User agents</a> SHOULD NOT expose descendants of this <a>element</a> through the platform <a>accessibility <abbr title="Application Programing Interface">API</abbr></a>. If <a>user agents</a> do not hide the descendant nodes, some information may be read twice.</p>
 		</section>
 		<section id="implictValueForRole">
 			<h3>Implicit Value for Role</h3>
@@ -11276,7 +11251,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 					<li>Description or general annotation: <code>aria-details</code> refers to an element with any other role.</li>
 				</ul>
 
-				<p>Unlike elements referenced by <code>aria-describedby</code>, elements referenced by <code>aria-details</code> are not used in the Accessible <a href="#mapping_additional_nd_description" class="accname">Description Computation</a> as defined in the Accessible Name and Description specification. Thus, the content of elements referenced by <code>aria-details</code> are not flattened to a string when presented to assistive technology users. This makes <code>aria-details</code> particularly useful when converting the information to a string would cause a loss of information or make the extended information more difficult to understand.</p>
+				<p>Unlike elements referenced by <code>aria-describedby</code>, elements referenced by <code>aria-details</code> are not used in the Accessible Description Computation as defined in the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]]. Thus, the content of elements referenced by <code>aria-details</code> are not flattened to a string when presented to assistive technology users. This makes <code>aria-details</code> particularly useful when converting the information to a string would cause a loss of information or make the extended information more difficult to understand.</p>
 				<p>The <code>aria-details</code> property supports referring to multiple elements. For example, a paragraph in a document editor may reference multiple comments that are not related to each other. If a user agent relies on an accessibility API that does not support exposing multiple descriptive relations, the user agent SHOULD expose the relationship to the first element referenced by <code>aria-details</code>.</p>
 				<p>It is valid for an element to have both <code>aria-details</code> and a description specified with either <code>aria-describedby</code> or <code>aria-description</code>. If a user agent relies on an accessibility API that does not support exposing multiple descriptive relations, and if an element has both <code>aria-details</code> and <rref>aria-describedby</rref>, the user agent SHOULD expose the <code>aria-details</code> relation and the description string computed from the <rref>aria-describedby</rref> relationship.</p>
 				<p>A common use for <code>aria-details</code> is in digital publishing where an extended description needs to be conveyed in a book that requires structural markup or the embedding of other technology to provide illustrative content. The following example demonstrates this scenario.</p>
@@ -11931,7 +11906,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 			<div class="property-description">
 				<p><a>Defines</a> a string value that labels the current element. See related <pref>aria-labelledby</pref>.</p>
 				<p>The purpose of <pref>aria-label</pref> is the same as that of <pref>aria-labelledby</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a>accessible name</a> property.</p>
-				<p>If the label text is available in the DOM (i.e. typically visible text content), authors SHOULD use <pref>aria-labelledby</pref> and SHOULD NOT use <pref>aria-label</pref>. There may be instances where the name of an element cannot be determined programmatically from the DOM, and there are cases where referencing DOM content is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g., the <code>title</code> attribute in [[HTML]]), yet this could present a browser tooltip. In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using <pref>aria-label</pref>. As required by the <a href="#textalternativecomputation">accessible name and description computation</a>, user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
+				<p>If the label text is available in the DOM (i.e. typically visible text content), authors SHOULD use <pref>aria-labelledby</pref> and SHOULD NOT use <pref>aria-label</pref>. There may be instances where the name of an element cannot be determined programmatically from the DOM, and there are cases where referencing DOM content is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g., the <code>title</code> attribute in [[HTML]]), yet this could present a browser tooltip. In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using <pref>aria-label</pref>. As required by the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]], user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
 			</div>
 			<table class="property-features">
 				<caption>Characteristics:</caption>
@@ -11966,7 +11941,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 			<div class="property-description">
 				<p><a>Identifies</a> the <a>element</a> (or elements) that labels the current element. See related <pref>aria-label</pref> and <pref>aria-describedby</pref>.</p>
 				<p>The purpose of <pref>aria-labelledby</pref> is the same as that of <pref>aria-label</pref>. It provides the user with a recognizable name of the object. The most common <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> mapping for a label is the <a>accessible name</a> property.</p>
-				<p>If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use <pref>aria-label</pref> and SHOULD NOT use <pref>aria-labelledby</pref>. As required by the <a href="#textalternativecomputation">accessible name and description computation</a>, user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
+				<p>If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use <pref>aria-label</pref> and SHOULD NOT use <pref>aria-labelledby</pref>. As required by the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]], user agents give precedence to <pref>aria-labelledby</pref> over <pref>aria-label</pref> when computing the accessible name property.</p>
 				<p>The <pref>aria-labelledby</pref> attribute is similar to <pref>aria-describedby</pref> in that both reference other elements to calculate a text alternative (an accessible name, and description, respectively). While a concise accessible name is preferable, a description can either be concise, or provide more verbose information.</p>
 				<!-- keep previous sentence synced with the associated description in #aria-describedby -->
 				<p class="note">The expected spelling of this property in <abbr title="United States">U.S.</abbr> English is "labeledby." However, the <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> features to which this property is mapped have established the "labelledby" spelling. This property is spelled that way to match the convention and minimize the difficulty for developers.</p>
@@ -12578,7 +12553,7 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
 				<p class="note">Text removals should only be considered relevant if one of the specified values is 'removals' or 'all'. For example, for a text change from 'foo' to 'bar' in a live region with a default <pref>aria-relevant</pref> value, the text addition ('bar') would be spoken, but the text removal ('foo') would not.</p>
 				<p><pref>aria-relevant</pref> is an optional attribute of live regions. This is a suggestion to <a>assistive technologies</a>, but assistive technologies are not required to present changes of all the relevant types.</p>
 				<p>When <pref>aria-relevant</pref> is not defined, an element's value is inherited from the nearest ancestor with a defined value. Although the value is a <a href="#valuetype_token_list">token list</a>, inherited values are not additive; the value provided on a descendant element completely overrides any inherited value from an ancestor element.</p>
-				<p>When text changes are denoted as relevant, user agents MUST monitor any descendant node change that affects the <a href="#textalternativecomputation">accessible name and description computation</a> of the live region as if the accessible name were determined from contents (<a href="#namecalculation">nameFrom: contents</a>). For example, a text change would be triggered if the HTML <code>alt</code> attribute of a contained image changed. However, no change would be triggered if there was a text change to a node outside the live region, even if that node was referenced (via <pref>aria-labelledby</pref>) by an element contained in the live region.</p>
+				<p>When text changes are denoted as relevant, user agents MUST monitor any descendant node change that affects the <cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]] of the live region as if the accessible name were determined from contents (<a href="#namecalculation">nameFrom: contents</a>). For example, a text change would be triggered if the HTML <code>alt</code> attribute of a contained image changed. However, no change would be triggered if there was a text change to a node outside the live region, even if that node was referenced (via <pref>aria-labelledby</pref>) by an element contained in the live region.</p>
 			</div>
 			<table class="property-features">
 				<caption>Characteristics:</caption>