RE: Moving Issues 62, 63, 71 to the conformance section

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Friday, July 14, 2017 10:12 AM

***
 it sort of puts a large burden on the author. Somebody asked them “do you intend this to be used on an Apple iPhone?” They would likely say yes, which would instantly bring a whole bunch of additional requirements on them for conforming with that specfic platform.
[Jason] According to my version of the proposal, this is not the case, unless the author (hypothetically) includes code specifically designed to support the Apple platform, at which point an obligation arises to ensure that the implementation techniques used work with the assistive technologies available on the platform that they’re explicitly supporting. This is how the two conditions of the proposal work together. The second condition is satisfied because there are specific assistive technologies on that platform.

An even bigger problem would be if you asked “is your content intended to be used on smartphones in general?”. In which case all of a sudden they would have to be aware of every access feature on every iPhone in general and ensure that their content is compatible with all of those 18, whatever they are.
[Jason] Again, the first of the two conditions in the proposal limits this issue.

A third concern is that you’re going to have to write sufficient techniques. And the only sufficient technique for this SC that I can think of is a technique that includes testing with every possible accessibility interface on every possible device, since that would be the only thing that would be sufficient to meet this criteria.   ... oh, this also defines what accessibility-supported means, and defines it as being different in this case than in any other case. That seems problematic as well.

[Jason] “Accessibility-supported” already requires compatibility with AT to be established, so it isn’t clear that there’s any new problem being introduced by the latest proposal. Now it’s also important to note here that the requirement is not to test the content for compatibility with AT, but that the means used to implement the success criteria must be accessibility-supported (i.e., shown to be compatible with the relevant AT). So the burden doesn’t actually lie on the individual content authors; it lies on the technique provider, and it’s sufficient for the authors to be using established techniques which are known to meet the AT-compatibility requirements that are included in the notion of “accessibility-supported”.
Thus I think the claim that additional burdens are imposed on individual content authors turns out to be misplaced. There is a testing burden – mostly handled by the technique developers who provide guidance to authors. If authors are doing something new and innovative, they might have to do the testing, but that seems to be a perfectly reasonable trade-off, otherwise users are prone to run into accessibility issues that should have been caught.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________