Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450)

marcoscaceres requested changes on this pull request.



>          </h2>
-        <p>
-          The <a>PaymentRequest</a> API does not directly support encryption of
-          data fields. Individual <a>payment methods</a> may choose to include
-          support for encrypted data but it is not mandatory that all
-          <a>payment methods</a> support this.
+        <p class="ednote">

I think this should be an "issue" pointing to the relevant bug in the issue tracker.  

> @@ -2428,58 +2428,71 @@
         </ol>
       </section>
     </section>
-    <section class='informative'>
-      <h2>
-        Security Considerations
-      </h2>
-      <p class="ednote">
-        This section is a placeholder to record security considerations as we
-        gather them through working group discussion.
-      </p>
-      <section>
+    <section class="informative">

I'm not sure there is much value in grouping these into a larger section. 

> -        </h2>
-        <p>
-          A page might try to call the payment request API repeatedly with only
-          one payment method identifier to try to determine what payment
-          methods a <a>user agent</a> has installed. There may be legitimate
-          scenarios for calling repeatedly (for example, to control the order
-          of payment method selection). The fact that a successful match to a
-          payment method causes a user interface to be displayed mitigates the
-          disclosure risk. Implementations may also require a user action to
-          initiate a payment request or they may choose to rate limit the calls
-          to the API to prevent too many repeated calls.
-        </p>
+      <section class="informative">
+          <h2>Accessibility Considerations</h2>
+          <p>
+          This specification has no defined user interface. In addition, there are no specific accessibility requirements on implementations. However, to the extent that an

I don't agree with this. There are absolutely accessibility requirements on the user interface:  for example, where the line items are shown, those much be accessible to people. Same with totals, etc. 

> -          A page might try to call the payment request API repeatedly with only
-          one payment method identifier to try to determine what payment
-          methods a <a>user agent</a> has installed. There may be legitimate
-          scenarios for calling repeatedly (for example, to control the order
-          of payment method selection). The fact that a successful match to a
-          payment method causes a user interface to be displayed mitigates the
-          disclosure risk. Implementations may also require a user action to
-          initiate a payment request or they may choose to rate limit the calls
-          to the API to prevent too many repeated calls.
-        </p>
+      <section class="informative">
+          <h2>Accessibility Considerations</h2>
+          <p>
+          This specification has no defined user interface. In addition, there are no specific accessibility requirements on implementations. However, to the extent that an
+          implementation provides user interactions in support of this specification, the implementation must ensure that the interface for those interactions is exposed to the
+          platform accessibility API. Moreover, implementors should take into consideration the needs of their users with varying abilities when designing solutions that

I don't think these generic statements are very helpful, tbh. I think we should be prescriptive where we can be. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/450#pullrequestreview-25692455