- From: James Nurthen <james.nurthen@oracle.com>
- Date: Wed, 08 Oct 2014 16:38:59 -0700
- To: Cynthia Shelly <cyns@microsoft.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
- Message-ID: <5435CB13.9060402@oracle.com>
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
> *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>
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:39:37 UTC