Editorial (Normative): "Web" to "web", harmonise when SC is upper or lowercase (#4461)

Split out normative-only version of
#4428

Relates to #4427

Changes unnecessary capitalisation of "Web" to "web", a few straggler
cases where lowercase "success criterion/criteria" was referring to
specific ones, where we do want title case

---------

Co-authored-by: Mike Gower <[email protected]>

Author: patrickhlauke

guidelines/index.html

@@ -116,7 +116,7 @@ <h4>Numbering in WCAG 2.2</h4>
 				</section>
 				<section id="conformance-to-wcag-2-2">
 					<h4>Conformance to WCAG 2.2</h4>
-					<p>WCAG 2.2 uses the same conformance model as WCAG 2.0. It is intended that sites that conform to WCAG 2.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better meeting the needs of users on the current Web. </p>
+					<p>WCAG 2.2 uses the same conformance model as WCAG 2.0. It is intended that sites that conform to WCAG 2.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better meeting the needs of users on the current web.</p>
 				</section>
 			</section>
         	<section id="later-versions-of-accessibility-guidelines">
@@ -539,7 +539,7 @@ <h2>Statement of Partial Conformance - Language</h2>
 
             <section class="informative" id="privacy-summary">
                 <h2>Privacy Considerations</h2>
-                <p>Success criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have privacy implications that the Working Group is not aware of at the time of publishing.</p>
+                <p>Success criteria within this specification which the Working Group has identified possible implications for privacy, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user privacy, are listed below. This list reflects the current understanding of the Working Group but other success criteria may have privacy implications that the Working Group is not aware of at the time of publishing.</p>
                 <p>Success criteria within this specification that may relate to privacy are:</p>
                 <ul>
                     <li><a href="#timeouts">2.2.6 Timeouts (AAA)</a></li>
@@ -550,7 +550,7 @@ <h2>Privacy Considerations</h2>
 
             <section class="informative" id="security-summary">
                 <h2>Security Considerations</h2>
-                <p>Success criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other Success criteria may have security implications that the Working Group is not aware of at the time of publishing.</p>
+                <p>Success criteria within this specification which the Working Group has identified possible implications for security, either by providing protections for end users or which are important for website providers to take in to consideration when implementing features designed to protect user security, are listed below. This list reflects the current understanding of the Working Group but other success criteria may have security implications that the Working Group is not aware of at the time of publishing.</p>
                 <p>Success criteria within this specification that may relate to security are:</p>
                 <ul>
                     <li><a href="#non-text-content">1.1.1 Non-text Content (A)</a></li>

guidelines/terms/20/accessibility-supported.html

@@ -102,7 +102,7 @@
       would be to consult compilations of uses that are documented to be accessibility supported.
       (See <a href="https://www.w3.org/WAI/WCAG22/Understanding/conformance#documented-lists">Understanding Accessibility-Supported Web Technology Uses</a>.) Authors, companies, technology vendors, or others may document accessibility-supported
       ways of using web content technologies. However, all ways of using technologies in
-      the documentation would need to meet the definition of accessibility-supported Web
+      the documentation would need to meet the definition of accessibility-supported web
       content technologies above.
    </p>
 

guidelines/terms/20/role.html

@@ -1,7 +1,7 @@
 <dt><dfn id="dfn-role">role</dfn></dt>
 <dd>
 
-   <p>text or number by which software can identify the function of a component within Web
+   <p>text or number by which software can identify the function of a component within web
       content
    </p>
 

guidelines/terms/20/technology.html

@@ -10,7 +10,7 @@
 
    <p class="note">Web content technologies may include markup languages, data formats, or programming
       languages that authors may use alone or in combination to create end-user experiences
-      that range from static web pages to synchronized media presentations to dynamic Web
+      that range from static web pages to synchronized media presentations to dynamic web
       applications.
    </p>