ACTION-2044: Separate out text from role="presentation/none"

This is desired so that a single location may be referenced by other
specs, such as the Core AAM.

* Initial proposal
* Make changes based on feedback from Joseph and others
* Address Amelia's comments on intrinsic host language semantics and
  common conflict section on the presentation role
* Remove some restrictions pertaining to native host language semantics
* Put Conflict Resolution content in a section
* Add exception to Conflicts with Host Language Semantics for permanently
  presentational roles

aria/aria.html

@@ -4686,7 +4686,7 @@ <h5 id="role-presentation-ednote-none">Editorial Note regarding the ARIA 1.1 <rr
 				<p>The <code>presentation</code> role is used on an element that has implicit native semantics, meaning that there is a default accessibility <abbr title="Application Programing Interface">API</abbr> role for the element. Some elements are only complete when additional descendant elements are provided. For example, in <abbr title="Hypertext Markup Language">HTML</abbr>, table elements (matching the <rref>grid</rref> role) require <code>tr</code> descendants (the <rref>row</rref> <a>role</a>), which in turn require <code>th</code> or <code>td</code> children (the <rref>gridcell</rref>, <rref>columnheader</rref>, <rref>rowheader</rref> roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> as <a href="#mustContain">required owned elements</a>.</p>
 				<p>When an explicit or inherited role of <code>presentation</code> is applied to an element with the implicit semantic of a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role that has <a href="#mustContain">required owned elements</a>, in addition to the element with the explicit role of <code>presentation</code>, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined. Also, when an explicit or inherited role of presentation is applied to a host language element which has required children as defined by the host language specification, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any required children that do not have an explicit role defined.</p>
 				<p>In <abbr title="Hypertext Markup Language">HTML</abbr>, the <a href="https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element"><code>img</code></a> <a>element</a> is treated as a single entity regardless of the type of image file. Consequently, using <code>role="presentation"</code> or <code>role="none"</code> on an <abbr title="Hypertext Markup Language">HTML</abbr> <code>img</code> is equivalent to using <code>aria-hidden="true"</code>. In order to make the image contents accessible, authors can embed the object using an <a href="https://www.w3.org/TR/html5/embedded-content-0.html#the-object-element"><code>object</code></a> or <a href="https://www.w3.org/TR/html5/embedded-content-0.html#the-iframe-element"><code>iframe</code></a> <a>element</a>, or use inline <abbr title="Scalable Vector Graphics">SVG</abbr> code, and follow the accessibility guidelines for the image content.</p>
-				<p>For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties for that element. For example, in <abbr title="Hypertext Markup Language">HTML</abbr>, a <code>ul</code> or <code>ol</code> element with a role of <code>presentation</code> will have the implicit native semantics of its <code>li</code> elements removed because the <rref>list</rref> role to which the <code>ul</code> or <code>ol</code> corresponds has a <a href="#mustContain">required owned element</a> of <rref>listitem</rref>. Likewise, although an <abbr title="Hypertext Markup Language">HTML</abbr> <code>table</code> element does not have an implicit native semantic role corresponding directly to a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role, the implicit native semantics of its <code>thead</code>/<code>tbody</code>/<code>tfoot</code>/<code>tr</code>/<code>th</code>/<code>td</code> descendants will also be removed, because the <abbr title="Hypertext Markup Language">HTML</abbr> specification indicates that these are required structural descendants of the <code>table</code> element. Explicit roles on a descendant or <a>owned</a> element override the inherited role of <code>presentation</code>, and cause the owned element to behave as any other element with an explicit role. If the action of exposing the implicit role causes the accessibility tree to be malformed, the expected results are undefined and the user agent MAY resort to an internal recovery mechanism to repair the accessibility tree.</p>
+				<p>For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties for that element. For example, in <abbr title="Hypertext Markup Language">HTML</abbr>, a <code>ul</code> or <code>ol</code> element with a role of <code>presentation</code> will have the implicit native semantics of its <code>li</code> elements removed because the <rref>list</rref> role to which the <code>ul</code> or <code>ol</code> corresponds has a <a href="#mustContain">required owned element</a> of <rref>listitem</rref>. Likewise, although an <abbr title="Hypertext Markup Language">HTML</abbr> <code>table</code> element does not have an implicit native semantic role corresponding directly to a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role, the implicit native semantics of its <code>thead</code>/<code>tbody</code>/<code>tfoot</code>/<code>tr</code>/<code>th</code>/<code>td</code> descendants will also be removed, because the <abbr title="Hypertext Markup Language">HTML</abbr> specification indicates that these are required structural descendants of the <code>table</code> element.</p>
 				<p class="note">Only the implicit native semantics of elements that correspond to <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a href="#mustContain">required owned elements</a> are removed. All other content remains intact, including nested tables or lists, unless those elements also have a explicit role of <code>presentation</code> applied.</p>
 				<p>For example, according to an accessibility <abbr title="Application Programing Interface">API</abbr>, the following markup elements would appear to have identical role semantics (no roles) and identical content.</p>
 				<pre class="example highlight"><span class="comment">&lt;!-- 1. [role="presentation"] negates the implicit 'list' and 'listitem' role semantics but does not affect the contents. --&gt;</span>
@@ -4702,14 +4702,7 @@ <h5 id="role-presentation-ednote-none">Editorial Note regarding the ARIA 1.1 <rr
 &lt;/foo&gt;</pre>
 				<p class="note">There are other <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles with required children for which this situation is applicable (e.g., radiogroups and listboxes), but tables and lists are the most common real-world cases in which the presentation inheritance is likely to apply.</p>
 				<p>For any element with an explicit or inherited role of <code>presentation</code>, user agents MUST apply an inherited role of <code>presentation</code> to all host-language-specific labeling elements for the presentational element. For example, a <code>table</code> element with a role of <code>presentation</code> will have the implicit native semantics of its <code>caption</code> element removed, because the caption is merely a label for the presentational table.</p>
-				<p>For any element with an explicit or inherited role of presentation, user agents MUST ignore any non-global, role-specific <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties. However, the user agent MUST always expose global <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties to accessibility <abbr title="Application Programing Interfaces">APIs</abbr>, even if an element has an explicit or inherited role of <code>presentation</code>.</p>
-				<p>For example,  <pref>aria-hidden</pref> is a global attribute and would always be applied; <pref>aria-level</pref> is not a global attribute and would therefore only apply if the element was not in a presentational state.</p>
-				<pre class="example highlight"><span class="comment">&lt;!-- 1. [role="presentation"] negates the implicit 'heading' role semantics but does not affect the global hidden state. --&gt;</span>
-&lt;h1 role="presentation" aria-hidden="true"&gt; Sample Content &lt;/h1&gt;
-
-<span class="comment">&lt;!-- 1. [role="presentation"] negates the both the implicit 'heading' and the non-global level. --&gt;</span>
-&lt;h1 role="presentation" aria-level="2"&gt; Sample Content &lt;/h1&gt;</pre>
-				<p>If an element with a role of presentation is focusable, user agents MUST ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both <a>understandable</a> and <a>operable</a>. Authors SHOULD NOT provide meaningful alternative text (for example, use <code>alt=""</code> in <abbr title="Hypertext Markup Language">HTML</abbr>) when the <code>presentation</code> role is applied to an image.</p>
+				<p>Authors SHOULD NOT provide meaningful alternative text (for example, use <code>alt=""</code> in <abbr title="Hypertext Markup Language">HTML</abbr>) when the <code>presentation</code> role is applied to an image.</p>
 				<p>In the following code sample, the containing <rref>img</rref> and is appropriately labeled by the caption paragraph. In this example the <code>img</code> element can be marked as presentation because the role and the text alternatives are provided by the containing element.</p>
 				<pre class="example highlight">&lt;div role="img" aria-labelledby="caption"&gt;
   &lt;img src="example.png" role="presentation" alt=""&gt;
@@ -4723,6 +4716,21 @@ <h5 id="role-presentation-ednote-none">Editorial Note regarding the ARIA 1.1 <rr
   &lt;/li&gt;
   …
 &lt;/ul&gt;</pre>
+				<section id="conflict_resolution_presentation_none">
+					<p><strong>Presentational Roles Conflict Resolution</strong></p>
+					<p>There are a number ways presentational role conflicts are resolved.</p>
+					<p>Host languages elements, having implicit presentational roles for which no roles, may be applied, MUST never be exposed to in the accessibility tree. With this exception, user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the <code>presentation</code> role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.</p>
+					<p>For example, <pref>aria-haspopup</pref> is a global attribute and would always be applied; <pref>aria-level</pref> is not a global attribute and would therefore only apply if the element was not in a presentational state.</p>
+					<pre class="example highlight">
+						<span class="comment">&lt;!-- 1. [role="presentation"] is ignored due to the global aria-haspopup property. --&gt;</span>
+&lt;h1 role="presentation" aria-haspopup="true"&gt; Sample Content &lt;/h1&gt;
+						<span class="comment">&lt;!-- 2. [role="presentation"] negates the both the implicit 'heading' and the non-global level. --&gt;</span>
+&lt;h1 role="presentation" aria-level="2"&gt; Sample Content &lt;/h1&gt;
+					</pre>
+					<p>Explicit roles on a descendant or <a>owned</a> element override the inherited role of <code>presentation</code>, and cause the owned element to behave as any other element with an explicit role. If the action of exposing the implicit role causes the accessibility tree to be malformed, the expected results are undefined and the user agent MAY resort to an internal recovery mechanism to repair the accessibility tree.</p>
+					<p>If an element with a role of presentation is focusable, or otherwise interactive, user agents MUST ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both <a>understandable</a> and <a>operable</a>.</p>
+					<p>User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the <code>presentation</code> role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.</p>
+				</section>
 			</div>
 			<table class="role-features">
 				<caption>Characteristics:</caption>
@@ -10838,7 +10846,7 @@ <h2>Conflicts with Host Language Semantics</h2>
 		<p>In addition to these normal situations in which <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is expected to override native semantics, there are elements that are inappropriate to override with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. This could be because identical host language semantics exist, so <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is not needed, or because semantics from <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> directly conflict with host language semantics. When a feature in the host language with identical role semantics and values is available, and the author has no compelling reason to avoid using the host language feature, authors SHOULD use the host language features rather than repurpose other elements with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>.</p>
 		<p>Host languages can have features that have implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics corresponding to roles. When a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role is provided, user agents MUST use the semantic of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role for processing, not the native semantic, unless the role requires <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties (for example, the HTML 'checked' attribute and the 'aria-checked' attribute could have conflicting values), and authors are expected to have valid reason to provide a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role even on elements that would not normally be repurposed.</p>
 		<p>When <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties correspond to host language features that have the same <a href="#implicit_semantics">implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantic</a>, it can be particularly problematic to use the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> feature. If the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> feature and the host language feature are both provided but their values are not kept in sync, user agents and assistive technologies cannot know which value to use. Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attributes on each host language element conflicts with native attributes for that element. When a host language declares a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attribute and instead use the host language attribute with the same implicit semantic.</p>
-		<p>Host languages MAY document features that cannot be overridden with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> (these are called "strong native semantics"). These can be features that have implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics, as well as features where the processing would be uncertain if the semantics were changed with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. Conformance checkers MAY signal an error or warning when a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs.</p>
+		<p>Host languages MAY document features that cannot be overridden with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> (these are called "strong native semantics"). These can be features that have implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics, as well as features where the processing would be uncertain if the semantics were changed with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. Conformance checkers MAY signal an error or warning when a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs unless the native host language semantic is permanently presentational.</p>
 		<p>The opportunity for host languages to create exceptions to the WAI-ARIA override of native features is meant to avoid potential author errors or problems with intrinsic processing of host language features. Author errors could happen when a host language and WAI-ARIA provide similar but not identical features, where it might not be clear how changing one but not the other affects the accessibility API. Intrinsic processing refers to the way a feature is processed, beyond simple rendering and exposure to the Accessibility API, that cannot reasonably be changed in response to a ARIA feature, and would lead to unpredictable results were ARIA allowed. In these situations, there is good reason for host languages to limit the scope of WAI-ARIA. However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used. Host languages should create restrictions on the use of ARIA only when it is critical to effective processing of content.</p>
 		<p>Certain ARIA features are critical to building a complete model in the accessibility API. Such features are not expected to conflict with native host language semantics (though they may complement them). Therefore, host languages MUST NOT declare strong native semantics that prevent use of the following ARIA features:</p>
 		<ul>