RE: Action 1500 - fixed zoom

"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
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>
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

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

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