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

Ø  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.

________________________________

Received on Monday, 4 July 2016 17:31:59 UTC