Re: Enabling Zoom on Mobile Devices

Thanks 
this is quite interesting and valuable.

Please note that Zoom compatibility is always an acceptable approach - so except where the author breaks zoomability — their content will pass.
IT would be good to document known ways to break zoom. 
These would not be failures (because the page might meet the SC in other ways) 
but it would be good to have a place where people can easily find things that would inadvertently break zoom so they can avoid them.
Even better would be to document other ways that achieve the same results and that do NOT break zoom
Is there an accessibility consulting house that would like to collect and post these on their website as a service to the field (and an example of their knowledge and prowess?) 

Also note that WCAG working group chose to not change (or write) the WCAG guidelines to work around bugs in Assistive technologies.   If the technique works with assistive technologies that are properly designed but not other AT that is not - the group did not want to punish web authors by making them do extra work in their software to make up for bad AT. 

gregg

> On Jan 16, 2015, at 12:29 AM, Detlev Fischer <detlev.fischer@testkreis.de> wrote:
> 
> I agree we need to find a position regarding the issue whether whether accessibility settings on mobile phones should be considered AT or just built-in features that can be used to meet a SC. 
> 
> System text scaling usually cannot meet SC 1.4.4 for *all* content. If you scale up text in a system's accessibility settings, many core apps will render some content that isn't scaled up at all, or not sufficiently. This is of course related to real estate viewport constraints - a designer who wants to fit all into the viewport often *cannot* support the font size setting on all elements without making a mess of it. Which is why zoom (system zoom or pinch zoom) will in most contexts be necessary. If we disallow the device zoom function to meet SC 1.4.4, chances are that many apps with layout optimised for small font sizes will not (fully) meet the SC.
> 
> I have just done extensive testing on iOS, Android (2 skins) and Windows Mobile and there are significant differences regarding the ability to use the zoom function and the built-in screen reader together. Only iOS currently follows focus when swiping through enlarged content. Android technically allows both features enabled but the experience os inferior for that reason (and due to much weaker focus visibility (thin yellow outline). I can provide a link to results soon.
> 
> Detlev
> 
> 
> On 16 Jan 2015, at 06:19, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
> 
>> 
>> 
>> gregg
>> 
>>> On Jan 15, 2015, at 8:37 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>>> 
>>> Gregg, go to m.wjla.com on an iPhone.    The page when viewed on the phone contains this meta tag.
>>> <meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0">
>>> 
>>> See a discussion of this setting below or anywhere else on the web.  This is a very common setting for reasons discussed in the thread.
>>> http://stackoverflow.com/questions/6397748/whats-the-point-of-meta-viewport-user-scalable-no-in-the-google-maps-api
>> 
>> 
>> The page works fine with the magnify feature on IOS.    just went there and zoomed to 800%.       (with and without voiceover)
>> 
>> (you can’t  pinch-zoom the page but you can three finger zoom it to what looks like 800%. )
>> 
>> 
>> This raises an interesting question though.   
>> Are access features that are built into a browser considered AT  or just universal design?  
>> Are access features built into an OS that has a built in browser considered AT or UD?
>> 
>> I have always considered access features that are built in as UD and access features that you must buy separately and install would be AT.     At least for the context of this discussion.
>> 
>> Some definitions of AT call anything that would be used to offset a persons impairments  so that they don’t experience a disability — (or experience less of a disability) — as being at.  So a pencil, and a lazy susan, and   lever door handles are all AT.   This was done to allow broad funding of things to help a person.    So are computers and any web page and a typewriter or word processor (for those who can’t handwrite) etc.  And that clearly is not the meaning of AT in this discussion.      So there are many definitions of AT.      So I don’t want to get into a discussion about all of them. 
>> 
>> 
>> But it think you raise some interesting practices that I think may be violations of the SC.   Not necessarily on mobile devices like the iPhone — where you do have a zoom/magnify feature that works fine on all these pages,  but on regular browsers where fixing boundaries or position of images or blocks could cause the page to be non-functional (or semi-non-functional) when the browser zoom is applied.    I think that might be a violation if it does this for all major browsers and the fixed position cannot be turned off by the user. (without needing to reprogram the page or stack style sheets etc that is beyond the typical user). 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> For another different but related issue visit www.cnn.com on an iPhone.  You will see that the site does enlarge but fixed positioned portions of the page cause the magnified main area of the page content to be very small.  While in this case you can technically get to everything and it would appear to pass, however, I can envision situations where some fixed positioned content might prevent access to the zoomed page because it overlaps when magnified to 200%.
>> 
>> 
>> 
>> 
>>> 
>>> Best Regards,
>>> 
>>> Jonathan
>>> 
>>> 
>>> -- 
>>> Jonathan Avila
>>> Chief Accessibility Officer
>>> SSB BART Group 
>>> jon.avila@ssbbartgroup.com
>>> 
>>> 703-637-8957 (o) 
>>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>> 
>>> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
>>> Sent: Thursday, January 15, 2015 8:14 PM
>>> To: Jonathan Avila
>>> Cc: Mike Elledge; GLWAI Guidelines WG org
>>> Subject: Re: Enabling Zoom on Mobile Devices
>>> 
>>> The zoom feature has nothing to do with the site. 
>>> 
>>> the web page has no idea that it is being zoomed.   Think of it as using a magnifying glass.   There is simply nothing that the web page can do to keep you from using a magnifying glass — or a  mobile zoom feature on the phone. 
>>> 
>>> You wrote:
>>> The zoom feature in Safari on iOS for example does not function when user scaling is blocked so as a person with a visual impairment I am prevented from zooming in on the page with browser zoom.
>>> 
>>> I know of no way to block the zoom feature.    I don’t know what you mean by ‘scaling’  but I never mentioned scaling.  I’m talking about zoom or magnify.   
>>> You cannot block magnify/zoom that I know of — so you cannot fail the SC. 
>>> 
>>> Can you show me a page (send me a URL) of any page that you think has magnification blocked?   
>>> I’ll give it a try.    There is always a chance that I am wrong… so willing to look if you think you have something that can block a magnification function.   don’t see how it can be done but willing to look. 
>>> 
>>> Thanks
>>> 
>>> gregg
>>> 
>>> On Jan 15, 2015, at 5:44 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>>> 
>>> Ø  Also, please note that the normal ZOOM feature in all browsers is sufficient to meet this requirement.   It is therefore virtually impossible today to not meet this SC unless you either
>>> 
>>> Greg, I have to disagree, if a site designed for mobile blocks user scaling then how can I use the browser zoom feature.  The zoom feature in Safari on iOS for example does not function when user scaling is blocked so as a person with a visual impairment I am prevented from zooming in on the page with browser zoom.  Can you please explain how this does not fail WCAG – the situation described above is assuming they don’t have another in-page or apple-system-xxx font techniques as discussed earlier..
>>> 
>>> In my experience most mobile browsers do not have a zoom capability when user scaling is turned off.   Only a few offer an option to override the setting.  IMO there is an accessibility support issue on mobile for this success criteria – there is not sufficient support in browser to override the setting and therefore it’s a failure.
>>> 
>>> Jonathan
>>> 
>>> -- 
>>> Jonathan Avila
>>> Chief Accessibility Officer
>>> SSB BART Group 
>>> jon.avila@ssbbartgroup.com
>>> 
>>> 703-637-8957 (o) 
>>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>> 
>>> From: CAE-Vanderhe [mailto:gregg@raisingthefloor.org] 
>>> Sent: Thursday, January 15, 2015 6:05 PM
>>> To: Mike Elledge
>>> Cc: GLWAI Guidelines WG org
>>> Subject: Re: Enabling Zoom on Mobile Devices
>>> 
>>> the width does not determine the enlargement. 
>>> 
>>> with responsive design you can have a fixed width and be able to enlarge the content 300% or more. 
>>> 
>>> Also, please note that the normal ZOOM feature in all browsers is sufficient to meet this requirement.   It is therefore virtually impossible today to not meet this SC unless you either
>>> 	• find some way to shrink your text to the same degree that someone zooms the browser  so that it doesn’t change size as you zoom’
>>> 	• you create content that can ONLY be viewed by a certain browser and that browser has no zoom.
>>> 
>>> 
>>> The problems being cited in the other posts are assuming things that are not required by WCAG. 
>>> 
>>> 
>>> Gregg
>>> 
>>> 
>>> 
>>> 
>>> On Jan 15, 2015, at 2:08 PM, Mike Elledge <melledge@yahoo.com> wrote:
>>> 
>>> Hi All--
>>> 
>>> Is it required under WCAG 2.0 AA that users can enlarge mobile sites to 200%? The question came up during our monthly accessibility forum, and I haven't been able to find anything about it online.
>>> 
>>> Apparently it is not uncommon for designers to set a fixed width for Responsive Web Designs, which, it seems to me, would be a violation of 1.4.4.
>>> 
>>> Your thoughts?
>>> 
>>> Mike
>> 
> 
> -- 
> Detlev Fischer
> testkreis - das Accessibility-Team von feld.wald.wiese
> c/o feld.wald.wiese
> Thedestraße 2
> 22767 Hamburg
> 
> Tel   +49 (0)40 439 10 68-3
> Mobil +49 (0)1577 170 73 84
> Fax   +49 (0)40 439 10 68-5
> 
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
> 
> 
> 
>