- From: James Nurthen <james.nurthen@oracle.com>
- Date: Wed, 08 Oct 2014 16:57:06 -0700
- To: Cynthia Shelly <cyns@microsoft.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
- Message-ID: <5435CF52.1050402@oracle.com>
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