- From: Shawn Lauriat <lauriat@google.com>
- Date: Tue, 29 Jan 2019 15:29:02 -0500
- To: Luis Garcia <w3c@garcialo.com>
- Cc: Silver TF <public-silver@w3.org>
- Message-ID: <CAGQw2hmn5ByVPWgyn7MjHCmjuYeQQEuzCJ67S3b5U8sbucd9WQ@mail.gmail.com>
Would it make a difference if all user agents had this feature? What if they all had it enabled by default? According to WCAG conformance, I agree and would still mark this as a failure. In the context of our conversation for Silver conformance, though, would/could we instead use this as a way to nudge other user agents into adding thing kind of support. Thanks, Shawn On Tue, Jan 29, 2019 at 3:19 PM Luis Garcia <w3c@garcialo.com> wrote: > If you use a user agent that ensures you can zoom, then it doesn't create > a barrier for you...while you're using that user agent. And while one user > agent having that ability implies that you could have it in another user > agent, it doesn't guarantee that you would (or even should) have it in > another user agent. While the barrier wouldn't exist for you, it would > still exist either until that functionality became guaranteed in all user > agents or the web page that disabled zooming stopped disabling it. > > I would say, it's still a failure and that the responsibility is with the > site developer. > > Perhaps in the same way that we would provide a method for ensuring a > contrast minimum for text, we could provide a method for ensuring zoomable > text/content. > > "Ensure that users can always zoom the page" and then gives guidance for > how to avoid building a page that creates this barrier. > > As an aside, the methods I've seen for disabling zooming has typically > been done via <meta name="viewport"...> elements with user-scalable="no" or > some value set for maximum-scale. > > luis > > On Tue, Jan 29, 2019 at 9:13 AM Shawn Lauriat <lauriat@google.com> wrote: > >> Forwarding a question from Josh on the main working group list that I'd >> like to expand on, given the conversation we had around conformance and >> user agent requirements. >> >> Flipping the question of how to express usability failure in terms of >> user agent / assistive tech / platform gaps around to the other case: >> currently, Chrome (Android) offers a setting to enable the user to remove >> the ability of a site to disable pinch zoom (Settings > Accessibility > >> Force enable zoom), but Chrome for iOS doesn't offer this (that I can find, >> at least). If I use a user agent that ensures I can zoom no matter what the >> content specifies, implying other user agents could very well offer the >> same feature, does this still constitute a failure? Does that failure's >> responsibility sit with the user agent or the CSS of the site? >> >> 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). >> >> What do you think? >> >> -Shawn >> >> On Tue, Jan 29, 2019 at 9:26 AM Joshue O Connor - InterAccess < >> josh@interaccess.ie> wrote: >> >>> Hi, >>> >>> In the failures section there are 'draft' failures listed. This one with >>> health warnings. >>> >>> >>> - @@ "Interfering with a user agent's ability to zoom" i.e., author >>> using: maximum-scale or minimum-scale or user-scalable=no or >>> user-scalable=0 in the meta element ?? @@ Note: In Pinch zoom thread >>> on the WCAG list >>> <https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0502.html> >>> people did not seem to be in favor of this as a failure. >>> >>> >>> While it would make a tidy failure if we could say - 'do not disable >>> pinch zoom'. If that's not a runner it should be removed as a failure as >>> its currently confusing to see it there. I see Jon and Patricks comments >>> after David posed the question. >>> >>> Any good reason for keeping it? >>> >>> Thanks >>> -- >>> Joshue O Connor >>> Director | InterAccess.ie >>> >>
Received on Tuesday, 29 January 2019 20:29:38 UTC