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

oops... typo should be ... Alastair

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

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:28 PM, David MacDonald <david100@sympatico.ca>
wrote:

> 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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>
> wrote:
>
>> Anyone know the status of indie UI?
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>> Tel:  613.235.4902
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> 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> wrote:
>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: Patrick H. Lauke [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.
>>>
>>> ________________________________
>>>
>>
>>
>