- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Tue, 5 Jul 2016 13:28:48 -0500
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>, WCAG <w3c-wai-gl@w3.org>, Low Vision Task Force <public-low-vision-a11y-tf@w3.org>
Hi Jonathan, > I’ve heard much higher numbers such as 800% thrown out there from the LVTF The latest LVTF proposal for an SC is 1100% based on Gordon Leege's studies. https://github.com/w3c/low-vision-SC/issues/5 Kindest Regards, Laura On 7/4/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > Ø We want you to make a responsive design that shifts to single column when > zoomed. > > Ø - If a user *does* zoom on their "desktop", we don't want them to loose > information from the "desktop" view/site. So don't drop content, and if you > do, make sure the user can get it back while staying in one column. > > In support of Gregg’s comments – perhaps we could put an exception in there > regarding content that cannot be reflow. Also responsive doesn’t have to > mean one column. A three column responsive site might go to two columns > first and then one column – or perhaps stay two columns if you need to > compare side by side information. > > > Ø I think also we should study options to increase the zoom requirement. > Perhaps the LVTF is doing this???... we need to know the sweet spot between > the burden on the developer, (we don't want to break her layout) and the > burden on the low vision user who wants to read the content. > > I’ve heard much higher numbers such as 800% thrown out there from the LVTF – > but due to time conflict with the mobile TF I have not been able to join the > TF calls in some time. > > Jonathan > > Jonathan Avila > Chief Accessibility Officer > SSB BART Group > jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com> > 703.637.8957 (Office) > > Visit us online: Website<http://www.ssbbartgroup.com/> | > Twitter<https://twitter.com/SSBBARTGroup> | > Facebook<https://www.facebook.com/ssbbartgroup> | > Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | > Blog<http://www.ssbbartgroup.com/blog/> > Check out our Digital Accessibility > Webinars!<http://www.ssbbartgroup.com/webinars/> > > From: David MacDonald [mailto:david100@sympatico.ca] > Sent: Monday, July 04, 2016 12:28 PM > To: White, Jason J > Cc: Patrick H. Lauke; public-mobile-a11y-tf@w3.org; WCAG > Subject: Re: Jonathan's concern: Zoom in responsive drops content > > One thing I don't want to do, is to discourage developers from using > responsive, because of the great advantage of single column layout for > people with Low Vision who are zooming in without the hassle of horizontal > scroll ... so it is a fine line balancing act... our message is to developer > I think is this: > > - We want you to make a responsive design that shifts to single column when > zoomed. > - If a user *does* zoom on their "desktop", we don't want them to loose > information from the "desktop" view/site. So don't drop content, and if you > do, make sure the user can get it back while staying in one column. > > Alestair says: >>>In a desktop context, then why not require zooming of 400%? Now that we >>> have responsive design, that is quite easy, it isn’t nearly the hardship >>> it was before when 200% was settled on > > I think also we should study options to increase the zoom requirement. > Perhaps the LVTF is doing this???... we need to know the sweet spot between > the burden on the developer, (we don't want to break her layout) and the > burden on the low vision user who wants to read the content. > > Cheers, > David MacDonald > > > > CanAdapt Solutions Inc. > Tel: 613.235.4902 > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd<http://twitter.com/davidmacd> > > GitHub<https://github.com/DavidMacDonald> > > www.Can-Adapt.com<http://www.can-adapt.com/> > > > > Adapting the web to all users > Including those with disabilities > > If you are not the intended recipient, please review our privacy > policy<http://www.davidmacd.com/disclaimer.html> > > On Mon, Jul 4, 2016 at 12:17 PM, David MacDonald > <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote: > Anyone know the status of indie UI? > > Cheers, > David MacDonald > > > > CanAdapt Solutions Inc. > Tel: 613.235.4902<tel:613.235.4902> > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd<http://twitter.com/davidmacd> > > GitHub<https://github.com/DavidMacDonald> > > www.Can-Adapt.com<http://www.can-adapt.com/> > > > > Adapting the web to all users > Including those with disabilities > > If you are not the intended recipient, please review our privacy > policy<http://www.davidmacd.com/disclaimer.html> > > On Mon, Jul 4, 2016 at 11:29 AM, White, Jason J > <jjwhite@ets.org<mailto:jjwhite@ets.org>> wrote: > > >> -----Original Message----- >> From: Patrick H. Lauke >> [mailto:redux@splintered.co.uk<mailto:redux@splintered.co.uk>] >> On 04/07/2016 15:22, Alastair Campbell wrote: >> > Secondly, if the user is in a mobile context (e.g. screenreader on a >> > smartphone) then they will be in the small screen version regardless >> > of zoom and require access to the same content & functionality. >> > Therefore all sizes of a responsive design must have equivalent >> > content & functionality. >> >> But Adam's point (which I also agree with in this context) is that looking >> purely at >> the "all users that are on a mobile device", they all get the equivalent >> experience, regardless of their ability/disability. >> So saying that a priori a reduced functionality small screen site is >> discriminating >> against users with disabilities on a mobile site isn't quite accurate. > > [Jason] I agree. Further, if we assume for the sake of discussion that the > entire site conforms to WCAG 2.0, then there's obviously no question of > conforming alternate versions, hence no requirement of equivalent content > and functionality established by WCAG as currently written. >> >> But, as already pointed out, since the small screen version can also be >> triggered >> in the desktop+zoom+small browser window scenario, THAT is a concern. >> > [Jason] Yes it is. If it's still possible to access all of the content and > functionality by invoking links, menu options or other UI controls, then I'm > less concerned by these scenarios. The content and functionality might not > all be on the same Web page as it is in the "large screen" view, but at > least it's available. > Where some of it is missing altogether, the user who seeks magnification > without horizontal scrolling is disadvantaged. Personalization techniques > could distinguish between the mobile device user, the large font user, and > the person who needs an uncluttered interface for cognitive reasons; but we > can't require this degree of personalization until we put the necessary > standards in place. There is scope within the ARIA working group to take up > the task from where the IndieUI working group finished, but this effort > hasn't started yet due to the necessary focus on completing ARIA 1.1. > > ________________________________ > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom it > is intended, even if addressed incorrectly. If you received this e-mail in > error, please notify the sender; do not disclose, copy, distribute, or take > any action in reliance on the contents of this information; and delete it > from your system. Any other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ________________________________ > > > -- Laura L. Carlson
Received on Tuesday, 5 July 2016 18:29:20 UTC