Re: Jonathan's concern: Zoom in responsive drops content

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