--- a/user-interface-safety.html	Wed Mar 12 22:16:10 2014 +0000
+++ b/user-interface-safety.html	Mon Jun 30 14:29:41 2014 -0700
@@ -1171,7 +1171,7 @@
 </section>
 
 </section>
-<section id="security-considerations" class=informative>
+<section id="security-considerations">
 <h2>Security Considerations</h2>
 
 
@@ -1235,39 +1235,40 @@
 rate of false positives, and perhaps to build a compatibility opt-out list of
 sites or resources to further reduce the false positive rate.</p>-->
 
-<section id="accessibility" class=informative>
+<section id="accessibility">
 <h3>Accessibility Technologies</h3>
 <p>Certain classes of accessibility technologies such as
 screen readers will provide strong defenses against many classes
 of UI Redressing attacks by presenting the content to the user
-in a manner not subject to interference. Such user agents
-SHOULD set the <code>unsafe</code> attribute of the <code>UIEvent</code>
-interface as this may be interrogated by client applications doing
-feature detection, and SHOULD ignore <code>X-Frame-Options</code>
-headers when presented in combination with UI Security directives in a
+in a manner not subject to interference. Such SHOULD ignore 
+<code>X-Frame-Options</code> headers when presented in 
+combination with UI Security directives in a
 Content Security Policy.</p>
 
 <p>Use of accessibility technologies MUST NOT by itself cause
 the <code>input-protection</code> heuristic to be triggered.
 Accessibility technologies that modify the appearance of a resource,
-such as screen magnifiers or color and contrast modifications to the 
-display have the potential to interfere with the <strong>obstruction
-check</strong>if not applied in a consistent manner to both the 
-<strong>user image</strong> and <strong>control image</strong>. 
-To prevent this inteference, user agents SHOULD apply accessibility
-transformations to the <strong>control image</strong> if possible. 
+such as screen magnifiers, contrast enhancers, or screen readers
+that highlight the element currently being read, have the potential to 
+interfere with the <strong>obstruction check</strong>. 
 If a user agent is able to detect that accessibility technologies are in use
-that cannot be applied uniformly as part of the <strong>obstruction
-check</strong>, the check MUST be disabled.  In some cases,
+that could cause interference, the check MUST be disabled.  In some cases,
 interference from accessiblity tools may be avoided by acquiring
 the <strong>user image</strong> in terms of the user agent's local
 rendering surface, rather than using an operating-system level 
 screenshot.</p>
 
-<p>User agents SHOULD provide a means for the user to manually disable
+<p>User agents MUST provide a means for the user to manually disable
 enforcement of the <strong>Input Protection Heuristic</strong> if it 
-interferes with their chosen accessibility technologies.</p>
+interferes with their chosen accessibility technologies. The mechanism 
+for manually disabling enforcement of the Input Protection Heuristic MUST
+be operable by assistive technolgies and by people with cognitive 
+disabilities who are able to understand the security risk</p>
 
+<p>Accessibility technologies that act as a proxy MAY filter
+any UISecurity policies if they cause interference with the user's
+chosen methods of accessing the content.</p>
+    
 </section>
 
 </section><section class=informative>
@@ -1275,7 +1276,10 @@
 
 <p>When possible, resource authors SHOULD make use of violation reports and the <code>unsafe</code> attribute to apply additional security measures in the application or during back-end processing.  Real-time measures in the application might include requiring completion of a CAPTCHA [[CAPTCHA-Wikipedia]] or responding to an out-of-band confirmation when the UI Security heuristic is triggered.  Example back-end measures might include increasing a fraud risk score for individual actions that trigger or targets accounts/resources that frequently trigger UI Security heuristics.  To be able to do this effectively, it is likely necessary to encode into the <code>report-uri</code> a unique identifier that can be correlated to the authenticated user and the action they are taking.</p>
 
-</section><section>
+<p>Mechanisms for CAPTCHA and user verification should include options for people with different disabilities, including cognitive disabilities, people with impaired visual and auditory discrimination skills, and for different modalities. For example, if CAPTCHA or user verification  require biometrics, a choice should be offered of what biometrics to use, as people with different disabilities may be unable to use one or more specific  biometric mechanisms. Further, when two step verification procedures are used, any time limit is problem and it should not be dependent on the user's short term memory or on the user's ability to copy accurately. See <a href="http://www.w3.org/TR/turingtest/">Inaccessibility of CAPTCHA</a> for more information about accessible CAPTCHA.</p>
+
+</section>
+<section>
 <h2>IANA Considerations</h2>
 
 <p>This document does not define new message headers and uses the existing grammar