Link the term "accessible name" to the AccName spec's definition (#3973)

Closes #3907

Author: patrickhlauke

understanding/20/consistent-identification.html

@@ -26,7 +26,7 @@ <h2>Intent of Consistent Identification</h2>
          components that appear repeatedly within a set of Web pages. A strategy that people
          who use screen readers use when operating a Web site is to rely heavily on their familiarity
          with functions that may appear on different Web pages. If identical functions have
-         different labels (or, more generally, a different <a href="https://www.w3.org/TR/accname-aam-1.1/">accessible name</a>)
+         different labels (or, more generally, a different <a href="https://www.w3.org/TR/accname/#dfn-accessible-name">accessible name</a>)
          on different Web pages, the site will be considerably more difficult
          to use. It may also be confusing and increase the cognitive load for people with cognitive
          limitations. Therefore, consistent labeling will help. 

understanding/21/label-in-name.html

@@ -21,11 +21,11 @@ <h2>In brief</h2>
 		<section id="intent">
 			<h2>Intent</h2>
 			<p>The intent of this Success Criterion is to ensure that the words which visually label a component are also the words associated with the component programmatically. This helps ensure that people with disabilities can rely on visible labels as a means to interact with the components.</p>
-			<p>Most controls are accompanied by a visible text <strong>label</strong>. Those same controls have a programmatic <strong>name</strong>, also known as the <a href="https://www.w3.org/TR/accname-aam-1.1/">Accessible Name</a>. Users typically have a much better experience if the words and characters in the visible label of a control match or are contained within the accessible name. When these match, speech-input users (i.e., users of speech recognition applications) can navigate by speaking the visible text labels of components, such as menus, links, and buttons, that appear on the screen. Sighted users who use text-to-speech (e.g., screen readers) will also have a better experience if the text they hear matches the text they see on the screen.</p>
+			<p>Most controls are accompanied by a visible text <strong>label</strong>. Those same controls have a programmatic <strong>name</strong>, also known as the <a href="https://www.w3.org/TR/accname/#dfn-accessible-name">accessible name</a>. Users typically have a much better experience if the words and characters in the visible label of a control match or are contained within the accessible name. When these match, speech-input users (i.e., users of speech recognition applications) can navigate by speaking the visible text labels of components, such as menus, links, and buttons, that appear on the screen. Sighted users who use text-to-speech (e.g., screen readers) will also have a better experience if the text they hear matches the text they see on the screen.</p>
 			<p>Note that where a visible text label does not exist for a component, this Success Criterion does not apply to that component.</p>
 			<p>Where text labels exist and are properly linked to the user interface components through established authoring practices, the label and name will normally match. When they don't match, speech-input users who attempt to use the visible text label as a means of navigation or selection (e.g., "move to Password") will be unsuccessful.  The speech-based navigation fails because the visible label spoken by the users does not match (or is not part of) the accessible name that is enabled as a speech-input command. In addition, when the accessible name is different from the visible label, it may function as a hidden command that can be accidentally activated by speech-input users.</p>
 			<p>Mismatches between visible labels and programmatic names for controls are even more of an issue for speech-input and text-to-speech users who also have cognitive challenges. Mismatches create an extra cognitive load for speech-input users, who must remember to say a speech command that is different from the visible label they see on a control. It also creates extra cognitive load for a text-to-speech user to absorb and understand speech output that does not match the visible label.</p>
-			<p>Note that when a <a>user interface component</a> lacks an <a>accessible name</a> — a failure of <a href="name-role-value">4.1.2 Name, Role, Value</a> — and has a visible text label, then it also fails this Success Criterion.</p>
+			<p>Note that when a <a>user interface component</a> lacks an <a href="https://www.w3.org/TR/accname/#dfn-accessible-name">accessible name</a> — a failure of <a href="name-role-value">4.1.2 Name, Role, Value</a> — and has a visible text label, then it also fails this Success Criterion.</p>
 
 			<h3>Identifying label text for components</h3>
 			<p>In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. There are often multiple text strings in a user interface that may be relevant to a control. However, there are reasons why it is best to conservatively interpret the label as being only the text in close proximity.</p>