W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

Re: Action 1500 - fixed zoom

From: James Nurthen <james.nurthen@oracle.com>
Date: Wed, 08 Oct 2014 16:57:06 -0700
Message-ID: <5435CF52.1050402@oracle.com>
To: Cynthia Shelly <cyns@microsoft.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
I'd be fine with these presuming the failures can be backed up with a 
WCAG success criteria they fail (and I agree that icons was probably missed)


On 10/8/2014 4:51 PM, Cynthia Shelly wrote:
>
> I think we are pretty close. Maybe broader techniques and tighter 
> failures might help with your concerns?  Something like
>
> Technique:  Not disabling zoom (list all the ways to disable zoom, 
> don't do it)
>
> Technique: Providing a custom zoom (several examples including profile 
> pic and maps)
>
> Technique: Using large hit targets (maybe this already exists and can 
> have some mobile examples added?)
>
> Technique: Using large icons
>
> Failure:  Small icons that cannot be resized (I'd have to look at WCAG 
> again to see if resizing only applies to text.  I think non-text is a 
> real issue, but we may not have covered it)
>
> Failure:  text that doesn't respond to platform text size settings 
> (maybe this already exists and can have some mobile examples added?)
>
> Failure: custom zooming that does not allow text resizing (I've seen 
> this in the wild.  I don't want to switch to a street view, I want the 
> name of the street bigger)
>
> Closer?
>
> *From:*James Nurthen [mailto:james.nurthen@oracle.com]
> *Sent:* Wednesday, October 8, 2014 4:39 PM
> *To:* Cynthia Shelly; public-pfwg@w3.org
> *Subject:* Re: Action 1500 - fixed zoom
>
> I think we are almost on the same page. I, however, don't want to 
> define "certain UI models where it is would be very inconsistent and 
> confusing if zoom were allowed" as there are always new UIs and new UI 
> models and any time we try to do these things we always end up with 
> unintended consequences.
> Zoom is certainly the easiest way for applications to support WCAG and 
> when I teach classes I tell people not to disable it - but there are 
> always exceptions and these exceptions (both the ones we know about 
> today and the ones we discover in the future) must not fall into the 
> cracks of a badly written failure technique.
>
> On 10/8/2014 4:19 PM, Cynthia Shelly wrote:
>
>     "These are usability issues."
>
>     I think this is the core of our disagreement.  I think they are
>     accessibility issues for people with mild to moderate vision
>     impairment and for older people.  Lack of zooming imposes a
>     barrier for users with these issues, which is not imposed on other
>     users.
>
>     Again, I don't want to disallow these features.  I want us to
>     define "certain UI models where it is would be very inconsistent
>     and confusing if zoom were allowed" via techniques and failures. 
>     Profile pictures expanding is an example of exactly that sort of
>     technique.  Icons below /n /pixels might be a failure (I say might
>     because I'm not sure we can define /n/ given the diversity of
>     screen sizes).  I disagree that in-app link and button size should
>     only be changeable via global settings, but I could support
>     multiple techniques, including responding to system settings,
>     zooming, or a minimum size.  Another technique might be
>     "implementing custom zoom behavior" which could include the
>     profile picture and map examples.
>
>     Does that make more sense?
>
>     *From:*James Nurthen [mailto:james.nurthen@oracle.com]
>     *Sent:* Wednesday, October 8, 2014 3:57 PM
>     *To:* Cynthia Shelly; public-pfwg@w3.org <mailto:public-pfwg@w3.org>
>     *Subject:* Re: Action 1500 - fixed zoom
>
>     Cynthia,
>     Please see inline...
>
>     On 10/8/2014 3:22 PM, Cynthia Shelly wrote:
>
>         I see it as an accessibility issue for users with mild to
>         moderate vision impairment (and everyone over 40).  Users
>         should not be required to set a global setting to see a
>         particular thing.  Global font settings also don't address the
>         scenario where the too-small thing is not text.  Profile
>         pictures are my favorite example, but icons, buttons and links
>         are sometimes too small too.
>
>     These are usability issues. I agree that I too find it annoying
>     when web sites have turned off zoom for no good reason - but there
>     are certain UI models where it is would be very inconsistent and
>     confusing if zoom were allowed. If the UI has been designed well
>     then all of the things that you cite would not be an issue.
>     Profile pictures, for example, should allow a user to tap on the
>     picture to open a full size zoomable version of the picture. Icons
>     should not be too small if well designed. They could also use icon
>     fonts and also respond to the global settings.
>     Buttons and links in a native application should respond to the
>     font size settings.
>
>
>
>         I think we should make some recommendations, via WCAG
>         techniques and failures, about where applications should
>         support zooming, when it makes sense to override it with
>         custom zooming, and when font sizing is sufficient.
>
>     I think we have to agree to disagree about this although I have no
>     problem if someone wants to create some positive techniques around
>     this or some combination failures where zoom is suppressed and
>     there is no other way (either OS or application specific) to
>     increase the font size a sufficient amount.
>     It is clearly not a WCAG failure if zoom is supressed and if text
>     can be resized to 200% by some method and I would be adamantly
>     opposed to any failure which stated as much. If you think there
>     should be a failure for this then you would have to look to the
>     next version of WCAG. However, personally I think that there
>     should not be any WCAG requirements for any specific technology
>     such as zoom. What happens when technology advances and zoom
>     becomes an obsolete way of meeting this requirement?
>
>
>
>         Since I see it as an accessibility issue, I'm leery of a
>         market argument.  Users with disabilities are too often in the
>         20% of the 80-20 rule.
>
>     If you are citing anyone over 40 as being in this category I think
>     the market is large enough to be listened to :)
>
>     Regards,
>     James
>
>
>         *From:*James Nurthen [mailto:james.nurthen@oracle.com]
>         *Sent:* Wednesday, October 8, 2014 3:06 PM
>         *To:* Cynthia Shelly; public-pfwg@w3.org
>         <mailto:public-pfwg@w3.org>
>         *Subject:* Re: Action 1500 - fixed zoom
>
>         For some apps I agree with you. For others I do not. This is
>         why it should be an app-specific decision as to whether this
>         is the right thing to do. I see zoom availability as a
>         potential usability issue and not an accessibility issue, so
>         long as there is a method to accomplish the text resize
>         functionality. So IMO we should let the market decide if this
>         is something that users want.
>
>         Regards,
>         James
>
>
>
>         On 10/8/2014 1:34 PM, Cynthia Shelly wrote:
>
>             I'm less convinced on this scenario.  It bugs me when apps
>             on my phone won't zoom, frankly.  I don't want to set
>             large fonts everywhere, but sometimes want to zoom in on a
>             particular part of an app.  I see this as a shortcoming in
>             the native apps, and not something to mimic in the web
>             platform.  Zooming is temporary and specific, where system
>             settings are permanent and pervasive.  They are very
>             different user behaviors. IMHO, both should be universally
>             supported.
>
>             *From:*James Nurthen [mailto:james.nurthen@oracle.com]
>             *Sent:* Wednesday, October 8, 2014 11:15 AM
>             *To:* public-pfwg@w3.org <mailto:public-pfwg@w3.org>
>             *Subject:* Re: Action 1500 - fixed zoom
>
>             A further type of applications where, in my opinion, it is
>             legitimate to disable zooming are web applications which
>             are attempting to mimic the look and feel of native apps.
>             On an iOS (I'm unsure how native apps look on other
>             platforms) device, for example, native applications
>             normally do not respond to zoom. Take a look at the iOS
>             Settings application. We have developers who want their
>             web apps to mimic native apps.
>             It is possible in Mobile Safari to use the fonts and the
>             zooming levels specified by the OS by specifying various
>             vendor-specific font styles in the style sheet. I would
>             prefer to focus our attentions on ways to allow the user's
>             font preferences to be used in web applications rather
>             than working against a feature which actually can enhance
>             usability when used in the correct ways in the correct
>             types of applications.
>
>             Regards,
>             James
>
>
>
>
>             On 10/8/2014 10:45 AM, Cynthia Shelly wrote:
>
>                 https://www.w3.org/WAI/PF/Group/track/actions/1500
>
>                 I was given a couple of use cases where I think this
>                 is legitimate. 1) is a game like Cut the Rope, where
>                 multi-touch is used for game interaction rather than
>                 zooming. 2) is Bing Maps, where the default zooming
>                 behavior is disabled and the app has created custom
>                 zooming behavior in javascript. I still worry about
>                 authors misusing this for 'normal' apps where users
>                 would expect zooming. I think WCAG failures/techniques
>                 are probably the best path here. I will also look into
>                 documenting accessibility concerns for these features
>                 in MSDN.
>
>                 IE supports the following ways to disable zooming.
>                 . <meta name="viewport" content="user-scalable=no">
>                 . <meta name="viewport" content="minimum-scale=1,
>                 maximum-scale=1">
>                 . document.addEventListener("touchmove", function(e)
>                 {e.preventDefault()})
>                 . html { touch-action: none; }
>                 . html { -ms-content-zoom-limit-min: 1;
>                 -ms-content-zoom-limit-max: 1; }
>
>             -- 
>             Regards, James
>
>             Oracle <http://www.oracle.com>
>             James Nurthen | Principal Engineer, Accessibility
>             Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> |
>             Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>
>             OracleCorporate Architecture
>             500 Oracle Parkway | Redwood City, CA 94065
>             Green Oracle <http://www.oracle.com/commitment>Oracle is
>             committed to developing practices and products that help
>             protect the environment
>
>         -- 
>         Regards, James
>
>         Oracle <http://www.oracle.com>
>         James Nurthen | Principal Engineer, Accessibility
>         Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile:
>         +1 415 987 1918 <tel:+1%20415%20987%201918>
>         OracleCorporate Architecture
>         500 Oracle Parkway | Redwood City, CA 94065
>         Green Oracle <http://www.oracle.com/commitment>Oracle is
>         committed to developing practices and products that help
>         protect the environment
>
>     -- 
>     Regards, James
>
>     Oracle <http://www.oracle.com>
>     James Nurthen | Principal Engineer, Accessibility
>     Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1
>     415 987 1918 <tel:+1%20415%20987%201918>
>     OracleCorporate Architecture
>     500 Oracle Parkway | Redwood City, CA 94065
>     Green Oracle <http://www.oracle.com/commitment>Oracle is committed
>     to developing practices and products that help protect the
>     environment
>
> -- 
> Regards, James
>
> Oracle <http://www.oracle.com>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 
> 987 1918 <tel:+1%20415%20987%201918>
> OracleCorporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065
> Green Oracle <http://www.oracle.com/commitment>Oracle is committed to 
> developing practices and products that help protect the environment
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Wednesday, 8 October 2014 23:57:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:09 UTC