editorial: definition of "host language"

Adds and exports a definition for host language.
Also incorporates some of the discussion in #2261.

Author: pkra

index.html

@@ -292,7 +292,7 @@ <h2>Rich Internet Application Accessibility</h2>
           The incorporation of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is a way for an author to provide proper semantics for custom widgets to make these widgets
           accessible, usable, and interoperable with assistive technologies. This specification identifies the types of widgets and structures that are commonly recognized by accessibility products,
           by providing an <a>ontology</a> of corresponding <a>roles</a> that can be attached to content. This allows elements with a given role to be understood as a particular widget or structural
-          type regardless of any semantics inherited from the implementing host language. Roles are a common property of platform
+          type regardless of any semantics inherited from the implementing <a>host language</a>. Roles are a common property of platform
           <a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> which assistive technologies use to provide the user with effective presentation and interaction.
         </p>
         <p>
@@ -427,8 +427,10 @@ <h2>User Agent Support</h2>
       <section id="co-evolution">
         <h2>Co-Evolution of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and Host Languages</h2>
         <p>
-          <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to augment semantics in supporting languages like [[HTML]] and [[SVG2]], or to be used as an accessibility
-          enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of
+          <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to be used as an accessibility enhancement technology in markup-based <a>host languages</a>. Examples include [[HTML]] and [[SVG2]], which both explicitly support the use of ARIA.
+        </p>
+        <p>
+          ARIA roles and properties clarify semantics to assistive technologies when authors create new types of
           objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them
           appears in web languages.
         </p>
@@ -16246,10 +16248,13 @@ <h2>Relationships in the Accessibility Tree</h2>
     <section class="normative" id="host_languages">
       <h1>Implementation in Host Languages</h1>
       <p>
-        The <a>roles</a>, <a>state</a>, and [=ARIA/properties=] defined in this specification do not form a complete web language or format. They are intended to be used in the context of a host
-        language. This section discusses how host languages are to implement <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, to ensure that the markup specified here will
+        The <a>roles</a>, <a>state</a>, and [=ARIA/properties=] defined in this specification do not form a complete web language or format. They are intended to be used in the context of a <a>host
+        language</a>. This section discusses how host languages are to implement <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, to ensure that the markup specified here will
         integrate smoothly and effectively with the host language markup.
       </p>
+      <p>
+        A <dfn data-export="">host language</dfn> is a markup-based language in which ARIA can be used as an accessibility enhancement technology. Examples include [[HTML]] and [[SVG2]], which both explicitly support the use of ARIA.
+      </p>
       <p>
         Although markup languages look alike superficially, they do not share language definition infrastructure. To accommodate differences in language-building approaches, the requirements are both
         general and modularization-specific. While allowing for differences in how the specifications are written, the intent is to maintain consistency in how the