Rewrite of Challenge #5, especially references to WCAG-EM and the Mit…

…igations section.

conformance-challenges/index.html

@@ -450,12 +450,24 @@ <h2>Challenge #5: The <q>Accessibility Supported</q> Requirement</h2>
 accessibility expertise, combined with the challenges mentioned above
 related to <a href="#Challenge-1">scaling accessibility assessment when human evaluation is
 		    required</a>, make the accessibility supported requirement a further
-challenge unto itself. There is a need for an external and international dialogue on this topic.
-</p>
-
-	<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., a specific set of assistive technologies in combination with some specific browser version. This is not only impractical and inadequate on the public web where multiple browsers and multiple assistive technologies are commonly employed, but also without normative status for this normative requirement of WCAG 2.</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&apos;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>
+	    challenge unto itself. <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-support-level-head">Understanding Conformance 2.0</a> further notes that: <q>There is a need for an external and international dialogue on this topic.</q>
+Meanwhile, the nonnormative <a href="https://www.w3.org/TR/WCAG-EM/#step1c">WCAG evaluation methodology (WCAG-EM)</a> advises approaches this conformance requirement by determining: <q>the minimum set of combinations of operating systems, web browsers, assistive technologies, and other user agents that the website is expected to work with, and that is in-line with the
+	WCAG 2.0 guidance on accessibility support.</q></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 in order to stake a conformance claim. This requirement greatly exaserbates <a href="#Challenge-2">Challenge #2 above</a>. It also exaserbates <a href="#Challenge-3">Challenge #3 above</a>, where it is concievable that some third party contribution might have been shown to conform to this requirement on its own, but with no knowledge of whether it would still conform in the hosted content environment.</p>
+
+	<p>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&apos;s not a
+	practical approach for solving the problem of end-to-end accessibility.
+	As the 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>
@@ -470,7 +482,10 @@ <h3>Silver Research Findings</h3>
 	<section class="mitigation">
 		<h3>Mitigations</h3>
 
-		<p>The defined baseline approach recommended by WCAG-EM (as cited above in this section) may provide a reasonable approach in a private environment where content, user agent, and an appropriate set of assistive technologies can be narrowly defined. Unfortunately, we know of no useable mitigations for public facing web sites.</p>
+		<p>We know of no useable mitigations to achieve the <a>Accessibility Supported</a> conformance requirement for public facing web sites. <a href="https://www.w3.org/TR/WCAG-EM/#step1c">WCAG-EM's Second Note</a> suggests that: <q>For some websites in closed networks, such as an intranet website, where both the users and the computers used to access the website are known, this baseline may be limited to the operating systems, web browsers and assistive
+technologies used within this closed network.</q> It continues saying: <q>However, in most cases this baseline is ideally broader to cover the majority of current user agents used by people with disabilities in any applicable particular geographic region and
+language community.</q> Beyond placing the responsibility on the evaluator to establish this baseline, <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">Note 5 in Understanding Conformance 2.0</a> suggests that: <q>One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported. ... Authors, companies, technology vendors, or others may document accessibility-supported ways of using Web content technologies.</q> Unfortunately, we know of no such public repository.
+	</p>
 	</section>
 	</section>