Further textual tweaks to Challenge #5.

conformance-challenges/index.html

@@ -409,9 +409,9 @@ <h2>Challenge #5: The <q>Accessibility Supported</q> Requirement</h2>
 		relied upon for conformance.</q>  However, the provided <a
 		href="https://www.w3.org/TR/WCAG21/#cc4">definition of
 		<q>Accessibility Supported</q></a>, leaves much to
-		interpretation, while the relevant section of <a
+		interpretation. Meanwhile the relevant section of <a
 			href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">Understanding
-			WCAG</a> notes: <q>This topic raises the question of
+			WCAG</a> further notes: <q>This topic raises the question of
 			how many or which assistive technologies must support a
 			Web technology in order for that Web technology to be
 			considered <q>accessibility supported</q>.  The WCAG
@@ -426,7 +426,7 @@ <h2>Challenge #5: The <q>Accessibility Supported</q> Requirement</h2>
 	<p>The <a href="https://www.w3.org/TR/WCAG-EM/#step1c">WCAG evaluation methodology (WCAG-EM)</a> approaches this conformance requirement by suggesting an individual audit determine what the accessibility support baseline should be; i.e., which browser + AT combinations need to work. If it
 	content works in those, it conforms to WCAG. Note that the same content may conform with one baseline but fail to conform when a different baseline is defined.</p>
 
-	<p>Not only does this conformance requirement of WCAG 2.x ask the content provider to check their content markup with commonly used browsers, it also asks that they further check usability with an undefined range of assistive technologies on commonly used operating environments. It is difficult to comprehend how a very large and highly dynamic site where millions (and even billions) of pages are updated by the minute could test to this degree in any meaningful way. Even testing a small sample of pages against several browsers on several operating systems becomes a hughe task when some arbitrary list of assistive technologies is also to be factored into testing for conformance. While the goal of <q>accessibility supported</q> may seem reasonable because it seeks to provide an accessible and usable experience for the site visitor who is a person relying on some assistive technology, it's not a practical approach to the problem. As the above cited text from WCAG documents demonstrates, even the group responsible for WCAG believes this concept needs more consideration.</p>
+	<p>Not only does this conformance requirement of WCAG 2.x ask the content provider to check their content markup with commonly used browsers, it also asks that they further check usability with an undefined range of assistive technologies on those same commonly used operating environments. It is difficult to comprehend how a very large and highly dynamic site where millions (and even billions) of pages are updated by the minute, often by third parties,  could test to this degree in any meaningful way. Even testing a small sample of pages against several browsers on several operating systems becomes a hughe task when some arbitrary list of assistive technologies is also to be factored into testing for conformance. While the goal of <q>accessibility supported</q> may seem reasonable because it seeks to provide an accessible and usable experience for the site visitor who must, after all, rely not only on the provided content, but a browser and some assistive technology, it's not a practical approach for solving the problem of end-to-end accessibility. As the above cited text from WCAG documents demonstrates, even the group responsible for WCAG believes this concept needs more consideration.</p>
 
 	<section class="silver">
 		    <h3>Silver Research Findings</h3>
@@ -441,7 +441,7 @@ <h3>Silver Research Findings</h3>
 	<section class="mitigation">
 		<h3>Mitigations</h3>
 
-		<p>The defined baseline approach recommended by ACT (as cited above in this section) provides a reasonable approach in a private environment where content, user agent, and assistive technologies can be narrowly defined. Unfortunately, we know of no useable mitigations for public facing web sites.</p>
+		<p>The defined baseline approach recommended by WCAG-EM (as cited above in this section) provides a reasonable approach in a private environment where content, user agent, and assistive technologies can be narrowly defined. Unfortunately, we know of no useable mitigations for public facing web sites.</p>
 	</section>
 	</section>