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

It is common in responsive design to provide different even limited
functionality for mobile users as David described. We should not disallow
such a design pattern under any circumstances.
Each view must be accessible. However, if a mobile user cannot access the
higher res view and instead is fed a limited mobile-oriented view and that
view is accessible then there is no discrimination against that user, for
all users in the mobile environment are given the same accessible
functionality.
Consider a situation where a webmaster has two sites, one of which provides
more functionality, while the other less. No violation here. Extending this
logic to a situation where the server feeds content and functionality based
on user preferences, so too no violation.
When access to functionality is determined by client scripts (but not
because of lack of accessibility) so too there should be no violation of
wcag.
Webmasters have the right to determine what content is available to users,
unless the criterion for that decision inherently discriminates against
users who require accessible content.


On Mon, Jul 4, 2016 at 2:35 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 04/07/2016 12:23, David MacDonald wrote:
>
> Jonathan says:
>>
>>> Responsive versions may have different functionality and some low
>>> vision users are forced into breakpoints by using zoom or low
>>> resolution they may not have access to content that would appear on
>>> other’s desktops even when they are using a desktop and that they
>>> can’t get the desktop functionality with their level of zoom or
>>> resolution – that remains an issue.
>>>
>>
>> Given Patrick's definition of the different types of responsive, we
>> should get an idea of which types of responsive more commonly drop
>> content on a small screen version. - Pure CSS breakpoints -
>> JavaScript which mimics/uses CSS breakpoints -UA sniffing on the
>> server side
>>
>> Would we want to require ALL the content from the desktop on the
>> responsive site? It may be optimized for a different use case than
>> the desktop view, people on the go trying to complete a task without
>> clutter... and people with cognitive disabilities may appreciate
>> less content...
>>
>
> In general: users should be able to get to the same functionality/content,
> regardless of any adaptations that were automatically made on the site/app
> based on factors such as device, user agent, screen size, etc. So as a very
> high-level goal, agree.
>
> We may want to develop a simple toggle switch that adds the dropped
>> content that was on the desktop view when responsive kicks in
>> WITHOUT forcing it back to the desktop view which requires horizontal
>> scroll on zoom in  ... if we make it easy, then perhaps we can
>> require it?
>>
>
> As there are many ways (from the very simple to the extremely complex) for
> a site to provide adaptations based on all sorts of factors, I think it's
> rather optimistic to think that we can simply provide a ready-made
> switch/button (and associated code) that authors can just drop into their
> site.
>
> I'd say the high-level principle is one that should be codified into an
> SC. The "How to achieve this" part needs to be left up to authors - though
> of course a super-simplified example to illustrate the point can be made,
> but certainly not required...especially as WCAG shouldn't (can't?) require
> actual technologies/techniques, but only require that the OUTCOME of the SC
> is met.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>