ACTION-1732: Conformance section for Core-AAM and Accname-AAM

Define what deprecated features mean for the mappings. In the process:
* change the conformance section to a respec-recognized conformance
  section (with auto heading)
* remove content that was redundant with respec-generated content
* create subsections for the new info on depcrecation as well as for the
  additional explanation on RFC-2119 and normative/non-normative
* allow references to "informative" definition via "non-normative" since
  that's what respec uses
* remove manual normative / informative declarations in favor of respec
  feature

Remove stray closing tag

Repeat the core-aam changes in accname-aam for conformance
Ref 3f0381b

Reset format of intro to minimize changes in pull request

But still replace the conformance section

accname-aam/accname-aam.html

@@ -133,7 +133,7 @@
 </section>
 <section id="sotd">
 </section>
-<section id="intro">
+<section id="intro" class="informative">
 	<h2>Introduction</h2>
       <p>This section is <a class="termref">informative</a>.</p>
       <p><a class="termref">User agents</a> acquire information from the <abbr title="Document Object Model">DOM</abbr> and create a parallel structure called the <a class="termref">accessibility tree</a>, made up of <a class="termref">accessible objects</a>.  An accessible object provides information about its <a class="termref">role</a>, <a class="termref">states</a>, and <a class="termref">properties</a>.  An example is an accessible object whose role is <code>menuitem</code>, is currently in an <code>enabled</code> state, with a <code>haspopup</code> property, indicating that it leads to a sub-menu.  </p>
@@ -142,21 +142,27 @@ <h2>Introduction</h2>
       <p><a class="termref">Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> currently support flat, unstructured strings for accessible names and descriptions.  The result of the name/description computation is thus a flat string. </p>      
       <p>The terms "accessible name" and "accessible description" are used to emphasize that they are properties of <a class="termref">accessible objects</a> as exposed by <a class="termref">Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a>.  However, they are frequently referred to hereafter as simply "name" and "description".</p>
 </section>
-<section id="normative" class="normative">
-	<h2>Normative User Agent Implementation Requirements for <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></h2>
-	<p>This section is <a class="termref">normative</a>.</p>
-	<p>This specification indicates whether a section is <a class="termref">normative</a> or <a class="termref">informative</a> and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.</p>
-	<p>Normative sections provide requirements that <a class="termref">user agents</a> must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in <cite><a href="http://www.rfc-editor.org/rfc/rfc2119.txt">Keywords for use in RFCs to indicate requirement levels</a></cite> [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and contained in a <code>strong</code> element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.</p>
-	<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
+<section id="conformance">
+<section>
+<h3>RFC-2119 Keywords</h3>
+<p>RFC-2119 keywords are formatted in uppercase and contained in a <code>strong</code> element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.</p>
+</section>
+<section>
+<h3>Normative and Informative Sections</h3>
+<p>The indication whether a section is <a class="termref">normative</a> or <a class="termref">non-normative</a> (informative) applies to the entire section including sub-sections.</p>
+<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
+</section>
+<section>
+<h3>Features Deprecated in WAI-ARIA</h3>
+<p>The WAI-ARIA specification <a href="#deprecated" class="specref">lists some features as deprecated</a>. Although this means authors are encouraged not to use such features, it is expected that the features could still be used in legacy content. Therefore, it is important that user agents continue to map these features to accessibility APIs, and doing so is part of conformance to this specification. When future versions of the WAI-ARIA specification change such features from deprecated to removed, they will be removed from the mappings as well and user agents will no longer be asked to continue support for those features.</p>
+</section>
 </section>
 <section id="glossary">
   <h2>Important Terms</h2>
-  <p>This section is <a class="termref">normative</a>.</p>
   <div data-include="../common/terms.html" data-oninclude="restrictReferences"></div>
 </section>
 <section id="mapping_additional_nd" class="normative">
   <h2>Name and Description</h2>
-  <p>This section is <a class="termref">normative</a>.</p>
   <p>The starting point of the name and description computation is a <abbr title="Document Object Model">DOM</abbr> <a class="termref">element</a>.  The output is a flat, unstructured string that can be as simple as a single word, or a string of space-separated tokens.  Examples include <code>Save</code> and <code>Reload from disk</code>.</p>
   <p>An important factor is the <a class="termref">element</a>'s <a class="termref">role</a>, that determines which content contributes to the name string.  Roles have a <code>nameFrom</code> <abbr title="Resource Description Framework">RDF</abbr> property, with two possible values:  </p>
   <dl class="runin">
@@ -165,7 +171,7 @@ <h2>Name and Description</h2>
     <dt>contents</dt>
     <dd>name is generated from the <a class="termref" data-lt="text node">Text nodes</a> associated with the <a class="termref">element</a>. Although this may be allowed in addition to "author" in some <a class="termref">roles</a>, "content" is used only if higher priority "author" features are not provided. Priority is defined by the <a href="#mapping_additional_nd_te">text alternative computation</a> algorithm.</dd>
   </dl>
-  <p>The <cite><a class="specref" href="#">Accessible Rich Internet Applications (WAI-ARIA) 1.1</a></cite> [[!WAI-ARIA]] specification provides lists of roles that support <a class="specref" href="#namefromauthor">name from author</code></a> and <a class="specref" href="#namefromcontent">name from content</a>. </p>
+  <p>The <cite><a class="specref" href="#">Accessible Rich Internet Applications (WAI-ARIA) 1.1</a></cite> [[!WAI-ARIA]] specification provides lists of roles that support <a class="specref" href="#namefromauthor">name from author</a> and <a class="specref" href="#namefromcontent">name from content</a>. </p>
   <section id="mapping_additional_nd_name">
     <h3>Name Computation</h3>
     <p><a class="termref">User agents</a> MUST compute an <a class="termref">accessible name</a> using the rules outlined below in the section titled <a href="#mapping_additional_nd_te">Text Alternative Computation</a>.</p>
@@ -479,4 +485,3 @@ <h2>Other substantive changes since the <a href="http://www.w3.org/TR/2014/REC-w
 </section>
 </body>
 </html>
-

common/terms.html

@@ -85,7 +85,7 @@
     <dd>
         <p>Indicates that the <a>element</a> is not visible, <a>perceivable</a>, or interactive to <em>any</em> user. An element is considered <em>hidden</em> if it or any one of its ancestor elements is not rendered or is explicitly hidden.</p>
     </dd>
-    <dt><dfn>Informative</dfn></dt>
+    <dt><dfn data-lt="non-normative">Informative</dfn></dt>
     <dd>
       <p>Content provided for information purposes and not required for conformance. Content required for conformance is referred to as <a>normative</a>.</p>
     </dd>

core-aam/core-aam.html

@@ -152,9 +152,8 @@
 </section>
 <section id="sotd">
 </section>
-<section id="intro">
+<section id="intro" class="informative">
 	<h2>Introduction</h2>
-      <p>This section is <a class="termref">informative</a>.</p>
       <p>In traditional desktop graphical user interface (GUI) applications, components of the user interface (UI) are displayed when needed and hidden when not needed based on user interactions. <a class="termref" data-lt="Accessibility APIs">Accessibility application programming interfaces (APIs)</a> are used to communicate <a class="termref">semantic</a> information about the user interface to <a class="termref">assistive technology</a> software used by people with disabilities. These <abbr title="application programming interfaces">APIs</abbr> constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular <abbr title="user interface">UI</abbr> component is a menu, button, text field, list box, etc.</p> 
       <p>In traditional static Web pages, the <abbr title="Hypertext Markup Language">HTML</abbr> <a class="termref">elements</a> provided the necessary semantic information. The <a class="termref">user agent</a> provides keyboard navigation but only to the <abbr title="Hypertext Markup Language">HTML</abbr> elements that are known to be interactive, specifically links and form elements. Assistive technologies obtain the semantic information from the Document Object Model (<abbr title="Document Object Model">DOM</abbr>) or, in the case of links and form elements, through the Accessibility <abbr title="Application Programming Interface">API</abbr>. In both cases, the assistive technology expects that nothing changes until a new page is loaded based on a user action. </p>
       <p>Yet technologies such as JavaScript, Ajax, and <abbr title="cascading style sheets">CSS</abbr> have enabled Web pages to look and behave more like interactive desktop <abbr title="graphical user interface">GUI</abbr> applications, without the need to reload the page with each user interaction. Developers can now re-purpose <abbr title="Hypertext Markup Language">HTML</abbr> elements into <abbr title="user interface">UI</abbr> components not previously defined in <abbr title="Hypertext Markup Language">HTML</abbr>. For example, Javascript can be used with <abbr title="cascading style sheets">CSS</abbr> to modify a <code>&lt;div&gt;</code> element based on user interactions to make it look and behave like a popup menu. Unfortunately, the <code>&lt;div&gt;</code> element does not provide the author with a vehicle to add semantic metadata that can be exposed through the <abbr title="Document Object Model">DOM</abbr> and mapped to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr>. These accessibility deficiencies in traditional markup render rich Internet applications unusable by people who use assistive technologies or who rely on keyboard navigation.</p>
@@ -230,21 +229,27 @@ <h5>Accessible Names and Descriptions</h5>
       </section>
     </section>
 </section>
-<section id="normative" class="normative">
-	<h2>Normative User Agent Implementation Requirements for <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></h2>
-	<p>This section is <a class="termref">normative</a>.</p>
-	<p>This specification indicates whether a section is <a class="termref">normative</a> or <a class="termref">informative</a> and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.</p>
-	<p>Normative sections provide requirements that <a class="termref">user agents</a> must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in <cite><a href="http://www.rfc-editor.org/rfc/rfc2119.txt">Keywords for use in RFCs to indicate requirement levels</a></cite> [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and contained in a <code>strong</code> element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.</p>
-	<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
+<section id="conformance">
+<section>
+<h3>RFC-2119 Keywords</h3>
+<p>RFC-2119 keywords are formatted in uppercase and contained in a <code>strong</code> element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.</p>
+</section>
+<section>
+<h3>Normative and Informative Sections</h3>
+<p>The indication whether a section is <a class="termref">normative</a> or <a class="termref">non-normative</a> (informative) applies to the entire section including sub-sections.</p>
+<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
+</section>
+<section>
+<h3>Features Deprecated in WAI-ARIA</h3>
+<p>The WAI-ARIA specification <a href="#deprecated" class="specref">lists some features as deprecated</a>. Although this means authors are encouraged not to use such features, it is expected that the features could still be used in legacy content. Therefore, it is important that user agents continue to map these features to accessibility APIs, and doing so is part of conformance to this specification. When future versions of the WAI-ARIA specification change such features from deprecated to removed, they will be removed from the mappings as well and user agents will no longer be asked to continue support for those features.</p>
+</section>
 </section>
 <section id="glossary">
   <h2>Important Terms</h2>
-  <p>This section is <a class="termref">normative</a>.</p>
 	<div data-include="../common/terms.html" data-oninclude="restrictReferences"></div>
 </section>
 <section class="section" id="keyboard-focus">
 	<h2>Supporting Keyboard Navigation</h2>
-  <p>This section is <a class="termref">normative</a>.</p>
 	<p>Enabling keyboard navigation in web applications is a necessary step toward making them accessible. <a class="termref">User agents</a> MUST provide a mechanism for authors to specify that any renderable <a class="termref">element</a> may be focusable without placing the element in a pre-defined tabbing order.</p>
 	<p>User agents MUST also provide programmatic access to all focusable elements. This allows for device-independent access, is needed to conform to the <cite><a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/">User Agent Accessibility Guidelines</a></cite> [[UAAG10]], and is vital for a successful implementation of <abbr title="accessible rich internet applications">WAI-ARIA</abbr>.</p>
   <p>Usable keyboard navigation in a rich Internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex <a class="termref">widgets</a>, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that <abbr title="accessible rich internet applications">WAI-ARIA</abbr> introduces to keyboard navigation make this enhanced accessibility possible. In <abbr title="accessible rich internet applications">WAI-ARIA</abbr>, any element can be keyboard focusable. In addition to host language mechanisms such as <code>tabindex</code>, <a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> provides another mechanism for keyboard operation. Most other aspects of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> widget  development depend on keyboard navigation functioning properly.</p>
@@ -369,7 +374,6 @@ <h3>Handling focus changes from the Assistive Technology</h3>
 </section>
 <section id="mapping">
 	<h2>Mapping <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></h2>
-    <p>This section is <a class="termref">normative</a>.</p>
 	<section id="mapping_general">
 		<h3>General rules for exposing <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> semantics</h3>
 		<p>Where supported by the platform <a class="termref" href="#dfn-accessibility-api">Accessibility <abbr title="Application Programming Interface">API</abbr></a>, <a class="termref">user agents</a> expose <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">semantics</a> through the  standard mechanisms of the desktop accessibility <abbr title="application programming interface">API</abbr>. For example, for  <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">widgets</a>, compare how the widget is exposed in a similar desktop  widget. In general most <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> widget capabilities are exposed through  the <a class="termref">role</a>, value, Boolean <a class="termref">states</a>, and relations of the accessibility <abbr title="application programming interface">API</abbr>.</p>
@@ -3214,7 +3218,6 @@ <h3>Special Events for Menus</h3>
 </section>
 <section id="document-handling">
 	<h2>Special Document Handling Procedures</h2>
-    <p>This section is <a class="termref">normative</a>.</p>
 	  <section id="document-handling_css-selectors">
 	    <h3>CSS Selectors</h3>
 		  <p class="ednote">This section might be removed in a future version.</p>