Re: Prohibiting authors from disabling Pinch Zoom as failure for Reflow 1.4.10

Alastair,

That all makes sense. We've so far talked about guidelines at the level of
user requirements and methods at the level of what
developers/authors/creators can do to meet them, as well as (still a bit
foggy here) how to assess their implementation of those methods in the
context of the user requirements (task-based assessment).

As such, if no method exists for the developer to meet a user requirement -
supported by user agents / assistive tech / the overall platform - then no
tests would apply to that particular thing until the platform (using as
shorthand for the mess of things making it up) supports a method to meet
it. I do think that the recent conversation on the main WG mailing list, What
is a failure of 1.3.5 Identify Input Purpose?
<https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/0079.html>,
uncovered two interesting aspects of that guidance that I think we need to
keep in mind for Silver:

   1. Identify Input Purpose
   <https://www.w3.org/TR/WCAG21/#identify-input-purpose> doesn't include
   anything about user need, only requiring that "The purpose of each input
   field collecting information about the user *can be programmatically
   determined*…" [emphasis mine], which opens up the ability for developers
   to meet the guidance by using a method where we don't have a list of
   assistive tech making use of it.
   2. The autocomplete technique does have support we can point to, while
   we don't have support we can point to for Microdata. How do we best express
   that gap in order to point to the need for a platform to support a new
   technique when we have an existing one (even if limited or not as helpful -
   a general statement, not making a judgement call on using autocomplete)?
   So far, we've talked about uncovering those gaps by calling out methods
   blocked by platform support, but I don't think we have the idea much more
   thought out than that (others, please correct me if that happened and I
   just missed the call or thread). ARIA makes another example, since we know
   of a non-English screen reader that doesn't support ARIA because its
   developers don't understand the ARIA spec well enough to implement it.
   These make just a couple of examples that hopefully show the range of
   support for things so we can talk about what level of support would
   "graduate" a method to recommended for meeting a guideline and how we might
   do so in the most effective way.

Thanks,

Shawn

On Wed, Jan 30, 2019 at 1:22 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Luis wrote:
>
> > I would say, it's still a failure and that the responsibility is with
> the site developer.
>
>
>
> This is a key thing to be able to say via conformance: *This is the level
> of responsibility for the website developer/designer/owner.*
>
>
>
>
>
> Shawn wrote:
>
> > Given our current direction of only having methods and not having
> "Failure techniques", I think this example would pass, as the user has ways
> to still zoom as needed, given that a cognitive walkthrough would take into
> account the user agent ability to override the zoom behavior of the site
> (just like user stylesheets can override site CSS).
>
>
>
> I suspect this would be a lot easier to do if the guidelines were oriented
> around user-requirements, e.g. “Users can increase the size of content”,
> with user-agents methods (having a zoom feature) and website methods (e.g.
> don’t disable pinch-zoom, use media queries).
>
>
>
> In that way you can construct the conformance with a mix of assumptions
> about user’s technology, and things the website must do to also support
> that.
>
>
>
> However, it doesn’t remove the need to have some sort of ‘accessibility
> supported’ concept, or a set of methods known to be supported in *general*
> at the time of publication.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> PS. I suspect the option isn’t in Chrome/iOS because Safari (and its
> engine that Chrome has to use on iOS) doesn’t respect that meta-viewport
> restriction any more.
>