Consistency: "user agent" rather than "user-agent" (#4845)

There's only a few straggler uses of "user-agent" (hyphenated). The
preferred usage is "user agent" (no hyphen).

Author: patrickhlauke

understanding/20/parsing.html

@@ -24,7 +24,7 @@ <h2>Intent of Parsing</h2>
       <div class="wcag22">
          <p>This criterion has been removed from WCAG 2.2.</p>
 
-         <p>The intent of this success criterion was to ensure that user-agents, including assistive technologies, can accurately interpret and parse content. Since WCAG 2.0 was published, the specifications (such as HTML) and browsers have improved their handling of parsing errors. It is also the case that assistive technology used to do their own parsing of markup, but now rely on the browser. For that reason this success criterion has been removed. Many issues that would have failed this criterion will fail <a href="info-and-relationships">Info and Relationships</a> or <a href="name-role-value">Name, Role, Value</a>. Other issues are excepted by the "except where the specification allow these features" part of the criterion.</p>
+         <p>The intent of this success criterion was to ensure that user agents, including assistive technologies, can accurately interpret and parse content. Since WCAG 2.0 was published, the specifications (such as HTML) and browsers have improved their handling of parsing errors. It is also the case that assistive technology used to do their own parsing of markup, but now rely on the browser. For that reason this success criterion has been removed. Many issues that would have failed this criterion will fail <a href="info-and-relationships">Info and Relationships</a> or <a href="name-role-value">Name, Role, Value</a>. Other issues are excepted by the "except where the specification allow these features" part of the criterion.</p>
 
          <p>The following content is left for historical purposes to show the original intent.</p>  
 

understanding/21/identify-input-purpose.html

@@ -26,7 +26,7 @@ <h2>Intent of this Success Criterion</h2>
   <p>This success criterion defines the types of user interface component input purposes, found in <a href="https://www.w3.org/TR/WCAG21/#input-purposes">Section 7 of the WCAG 2.1 Recommendation</a>, that must be programmatically identifiable. When these user input purposes are present, and if the technology supports doing so, the field purpose must be programmatically identifiable.</p>
   <p>The HTML <code>autocomplete</code> attribute only accepts a certain number of specific well-defined fixed values. This allows a more fine-grained definition or identification of purpose than the type attribute, for example, by allowing the author to specify a specific type of name: Name (<code>autocomplete="name"</code>), Given Name (<code>autocomplete="given-name"</code>), Family Name (<code>autocomplete="family-name"</code>), as well as Username (<code>autocomplete="username"</code>), and Nickname (<code>autocomplete="nickname"</code>).</p>
   <p>By adopting and repurposing this predefined taxonomy of definitions, user agents and assistive technologies can now present the purpose of the inputs to users in different modalities. For example, assistive technologies may display familiar icons next to input fields to help users who have difficulties reading. An icon of a birthday cake may be shown in front of an input field with <code>autocomplete="bday"</code>, or the icon of a telephone in front of an input field with <code>autocomplete="tel"</code>.</p>
-  <p>In addition to repurposing this taxonomy, when the autocomplete attribute technique is used to meet this Success Criterion, browsers and other user-agents can suggest and 'autofill' the right content by autocompleting these fields based on past user input stored in the browser. By defining more granular definitions of common input purposes, for example “Birthday” (<code>autocomplete="bday"</code>), browsers can store personalized values for each of these fields (the user's birthday date). The user is relieved of having to type the information and can instead confirm or, if needed, change the value of the field, a significant benefit for users with memory issues, dyslexia, and other disabilities. Because the <code>autocomplete</code> values are independent of language, users that may not be familiar with the text used to visually identify user input fields (the label) can still have that purpose consistently identified to them due to the fixed taxonomy of terms.</p>
+  <p>In addition to repurposing this taxonomy, when the autocomplete attribute technique is used to meet this Success Criterion, browsers and other user agents can suggest and 'autofill' the right content by autocompleting these fields based on past user input stored in the browser. By defining more granular definitions of common input purposes, for example “Birthday” (<code>autocomplete="bday"</code>), browsers can store personalized values for each of these fields (the user's birthday date). The user is relieved of having to type the information and can instead confirm or, if needed, change the value of the field, a significant benefit for users with memory issues, dyslexia, and other disabilities. Because the <code>autocomplete</code> values are independent of language, users that may not be familiar with the text used to visually identify user input fields (the label) can still have that purpose consistently identified to them due to the fixed taxonomy of terms.</p>
   <p>If an input field accepts two different types of input purpose (as in combined user name/user email fields) and the technology used does not allow multiple purpose values to be defined, it is valid to provide either one or the other value or leave out the designation of input purpose altogether.</p>
   <p>When the user agent and assistive technology support for other metadata formats matures, metadata schemes like the <a href="https://www.w3.org/TR/adapt-symbols/">WAI-Adapt: Symbols Module</a> may be used in addition or instead of the HTML autocomplete attribute to identify the purpose of input fields. They can also support automated adaptations that identify and match author-provided input labels to defined vocabularies or symbols that are used instead for labelling inputs.</p>
   <p class="note">The term <q>input</q> is used here as a generic way to refer to form controls that accept user input. For instance, in HTML, it is not limited to the <code>&lt;input&gt;</code> element, but also covers other controls such as <code>&lt;select&gt;</code>.</p>

understanding/21/non-text-contrast.html

@@ -215,7 +215,7 @@ <h3>User Interface Component Examples</h3>
 						</tr>
 						<tr>
 							<th>Default focus style</th>
-							<td>Links are required to have a visible focus indicator by <a href="focus-visible.html">2.4.7 Focus Visible</a>. Where the focus style of the user-agent is not adjusted on interactive controls (such as links, form fields or buttons) by the website (author), the default focus style is exempt from contrast requirements (but must still be visible).</td>
+							<td>Links are required to have a visible focus indicator by <a href="focus-visible.html">2.4.7 Focus Visible</a>. Where the focus style of the user agent is not adjusted on interactive controls (such as links, form fields or buttons) by the website (author), the default focus style is exempt from contrast requirements (but must still be visible).</td>
 							<td>{% include "./img/1.4.11-ntc-default-link-focus.svg" %}</td>
 						</tr>
 						<tr>

understanding/22/dragging-movements.html

@@ -38,7 +38,7 @@ <h2>Intent of Dragging Movements</h2>
 
       <p>This requirement is separate from keyboard accessibility because people using a touch screen device may not use a physical keyboard. Keyboard specific interactions such as tabbing or arrow keys may not be possible when encountering a drag and drop control. Note, however, that providing a text input can be an acceptable single-pointer alternative to dragging. For example, an input beside a slider could allow any user to enter a precise value for the slider. In such a situation, the on-screen keyboard that appears for touch users offers a single-pointer means of entering an alphanumeric value.</p>
 
-      <p>This criterion does not apply to scrolling enabled by the user-agent. Scrolling a page is not in scope, nor is using a technique such as <abbr title="Cascading Style Sheets">CSS</abbr> <code>overflow</code> to make a section of content scrollable.</p>
+      <p>This criterion does not apply to scrolling enabled by the user agent. Scrolling a page is not in scope, nor is using a technique such as <abbr title="Cascading Style Sheets">CSS</abbr> <code>overflow</code> to make a section of content scrollable.</p>
 
 		<section>