Section for A11Y Considerations #450
Conversation
| 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"> |
There was a problem hiding this comment.
I think this should be an "issue" pointing to the relevant bug in the issue tracker.
There was a problem hiding this comment.
I am not sure why this showed up in this PR, but this is not content related to the change request and I don't have a preference. It isn't my text.
| gather them through working group discussion. | ||
| </p> | ||
| <section> | ||
| <section class="informative"> |
There was a problem hiding this comment.
I'm not sure there is much value in grouping these into a larger section.
There was a problem hiding this comment.
Each item was so small as to beg the question why would a top level section be in place for them. Moreover, as they are all related to W3C horizontal review requirements, it felt sensible to gather them together to me.
| <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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
No. The specification explicitly has no UI requirements. There is no requirement that any of that information be presented at all. And it is outside of the charter of the group to specify UI requirements. It is up to user agents and payment apps.
There was a problem hiding this comment.
The specification doesn't explicitly define a UI, however, it can and as Marcos suggests should define functional interface requirements for accessibility.
| <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 |
There was a problem hiding this comment.
I don't think these generic statements are very helpful, tbh. I think we should be prescriptive where we can be.
There was a problem hiding this comment.
Understood. But without specific UI requirements that is basically impossible. The APA has indicated that this sort of guidance is sufficient for their current purposes (although they are also producing a Payment Accessibility User Requirements document that will have more specific examples).
There was a problem hiding this comment.
This is not consistent with itself. There is a concrete accessibility requirement named: That anything exposed in the UI is exposed to the accessibility API.
This seems necessary but not sufficient. Information needs to meet accessibility requirements for users other than those who rely on the accessibility API, too.
|
Is there a good example of a W3C spec that includes a requirement to ensure that data sent through the API is available to the user agent's accessibility API? Ian |
You might not want to constrain your own spec quite so tightly. The goal is to be useful, after all. |
|
@chaals and @halindrome, From @chaals' reference to HTML AAM [1] I am gathering that the idea would be to map the data flowing through the system (e.g., address, currency, amount, and so forth) to familiar platform-specific accessibility APIs. @halindrome, would you be able to start a companion document that does so for the data elements of PR API? Ian |
|
Given that there has been no movement on this for the last few months, closing. |
|
(Sorry, I thought I had said this when it was timely :( Apparently not.)
Not at all. The idea would be to say, as noted in @marcoscaceres' comments on the PR, that it is vital that the data presented is accessible to users. Pushing them to an accessibility API is not going to achieve that for most users, and is quite possibly unnecessary even for the few users who can potentially benefit from it. |
in light of previous discussion of: #450
in light of previous discussion of: #450
4 participants
As per an APA Resolution ages ago [1] , this PR integrates text to help clarify that there are no explicit A11Y requirements but that implementors should ensure the UI they end up providing is one where A11Y is taken into account.
[1] http://lists.w3.org/Archives/Public/public-apa/2016Aug/0080.html
Preview | Diff