- From: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Date: Thu, 15 Jan 2015 23:19:45 -0600
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: Mike Elledge <melledge@yahoo.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-Id: <8417AA17-2454-48D5-B068-298B6488C81C@raisingthefloor.org>
gregg > On Jan 15, 2015, at 8:37 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > > Gregg, go to m.wjla.com <http://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 <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 <http://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 <mailto:jon.avila@ssbbartgroup.com> > > 703-637-8957 (o) > Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP> > > 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 <mailto: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 <mailto:jon.avila@ssbbartgroup.com> > > 703-637-8957 (o) > Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP> > > From: CAE-Vanderhe [mailto:gregg@raisingthefloor.org <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 <mailto: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
Received on Friday, 16 January 2015 05:20:17 UTC