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

>> I think the onus of proof lies on those who are running the above
objection against my proposal

Here's Gregg's response to the proposal:

***
 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.

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.

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.

***

To be fair, he didn't like my language about screen sizes either. So I'm
not sure where we are at.

Most evaluators consider Mobile menus to be part of the entire responsive
page in WCAG 2.0 and Loretta who was chair of WCAG  2 also believes that.
https://github.com/w3c/wcag/issues/197

So maybe just drop it and let the ambiguity hang.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jul 14, 2017 at 9:40 AM, David MacDonald <david100@sympatico.ca>
wrote:

> There is always a balance... if we widen requirements too much the testing
> burden will be too high. If we narrow then then we may leave behind users.
> We have to remember that changes to confromance requirements are huge.
>
> if we adopt your language Jason then it will be so wide that we've changed
> accessibility support from one stack, to multiple stacks, increasing
> testing costs and effort to meet WCAG exponentially.
>
> I ran your language by Gregg and that was exactly what his worry was also,
> that testing and conformance requirements would increase multiple factors.
>
> On the mobile task force we had extensive discussions about this and the
> line we drew was to limit the AT to the ones that get messed up.
>
> "Platform assistive technology that remap touch gestures."
>
> Today this means screen readers that ship with OS but it might widen in
> the future. This requirement is coming out of the mobile task force.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Fri, Jul 14, 2017 at 8:49 AM, White, Jason J <jjwhite@ets.org> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Patrick H. Lauke [mailto:redux@splintered.co.uk]
>> > Also, authors may change things based not just on screen size, but
>> other factors
>> > (feature-detecting presence of a particular API or sensor).
>> [Jason] This is exactly in accord with my argument for the more general
>> solution.
>>
>> ________________________________
>>
>> 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.
>>
>> ________________________________
>>
>
>

Received on Friday, 14 July 2017 14:12:54 UTC