Edits to Challenge #4 including a new second paragraph. Note the clas…

…s=mitigation label for possible css styling.

conformance-challenges/index.html

@@ -131,8 +131,31 @@ <h3>Treatment of 3rd party content and Statements of Partial Conformance</h3>
         </section>
         <section id="Challenge-4">
             <h2>Challenge #4: Non-Web Information and Communications Technologies </h2>
-            <p>The core principles, and many of the guidelines, contained in WCAG 2.x, are broadly applicable outside of the web context. For example, no matter the technology, information presented to humans needs to be perceivable by them in order for them to access and use it. At the same time, some of the specific guidelines and especially some of the individual success criteria of WCAG 2.x are written specifically for web content and web technologies, and may be difficult to apply to non-web information and communications technologies (as set forth in the W3C Note <a href="https://www.w3.org/TR/wcag2ict/">Guidance on Applying WCAG to Non-Web Information and Communication Technologies (WCAG2ICT)</a>). [[wcag2ict]] Furthermore, the state of programmatic test tools for assessing whether non-web information and communications technologies meet various WCAG 2.x success criteria varies widely with the type of non-web document, the operating system and user interface toolkits used to create the non-web software. In no case that we are aware of do such tools explicitly map the accessibility issued found to specific WCAG 2.x success criteria. Therefore, it is potentially the case that for some documents or software, it will not be possible to use any programmatic accessibility evaluation tools for any success criterion – conformance to each and every success criterion will need human expertise and judgment.</p>
-	    <p><a href="#Appendix-B">Appendix B</a> contains <q>Detailed Challenges with Conformance Verification and Testing for non-Web ICT.</q> It covers the 12 success criteria out of the 38 A and AA criteria in WCAG 2.0 which could be applied to non-Web ICT only after replacing specific terms or phrases, as well as a growing list of success criteria introduced in WCAG 2.1 that also pose specific challenges for conformation verification and testing in the non-Web ICT context.</p>
+            <p>The core principles, and many of the guidelines, contained in WCAG 2.x, are broadly applicable outside of the web context. For example, no matter the technology, information presented to humans needs to be perceivable by them in order for them to access and use it. At the same time, some of the specific guidelines and especially some of the individual success criteria of WCAG 2.x are written specifically for web content and web technologies, and may be difficult to apply to non-web information and communications technologies (as set forth in the W3C Note <a href="https://www.w3.org/TR/wcag2ict/">Guidance on Applying WCAG to Non-Web Information and Communication Technologies (WCAG2ICT)</a>). [[wcag2ict]] Furthermore, the state of programmatic test tools for assessing whether non-web information and communications technologies meet various WCAG 2.x success criteria varies widely with the type of non-web document, the operating system, and the user interface toolkits used to create the non-web software. In no case that we are aware of do such tools explicitly map the accessibility issued found to specific WCAG 2.x success criteria. Therefore, it is potentially the case that for some documents or software, it will not be possible to use any programmatic accessibility evaluation tools for any success criterion &mdash; conformance to each and every success criterion will need human expertise and judgment.</p>
+
+<p class="mitigation">There are various approaches to the challenges of accessibility guidelines
+conformance and testing of non-web information and communications
+technologies, depending upon the nature of non-web document technology or
+non-web software in question.  For example, there is a rich set of techniques
+describing how to meet WCAG success criteria for Adobe PDF documents, and
+Adobe includes a PDF accessibility assessment tool that also helps authors
+mitigate accessibility failings found by the tool as part of Adobe Acrobat.
+Both Microsoft Word and OpenOffice include accessibility test and validation
+tools, and both are capable of saving exporting their content into accessible
+PDF documents.  Operating systems like MacOS, iOS, Windows, Android, and Fire
+OS all have rich accessibility frameworks which can be used to make accessible
+software applications, which are accessible through the use of built-in
+assistive technologies like screen readers and screen magnifiers, as well as
+3rd party assistive technologies in some cases.  Further, there are a variety
+of accessibility test tools and support systems to help software developers
+make accessible software applications for these operating systems.  While none
+of these tools and frameworks can find all accessibility issues or otherwise
+guarantee a document or application will be free of all accessibility defects
+– whether those are tied to a specific WCAG success criterion or not – they
+are nonetheless important tools that can lead to highly accessible documents
+and software.
+</p>
+	    <p class="mitigation"><a href="#Appendix-B">Appendix B</a> contains <q>Detailed Challenges with Conformance Verification and Testing for non-Web ICT.</q> It covers the 12 success criteria out of the 38 A and AA criteria in WCAG 2.0 which could be applied to non-Web ICT only after replacing specific terms or phrases, as well as a growing list of success criteria introduced in WCAG 2.1 that also pose specific challenges for conformation verification and testing in the non-Web ICT context.</p>
         </section>
         <section>
             <h2>Challenges of Conformance as identified from Silver Research</h2>