Re: Conforming alternative for mobile should not be Desktop

On 30/06/2016 17:44, David MacDonald wrote:
>>>In a responsive site you would not get a link to a ‘desktop’ version.
>
> I think this is very common.  I have seen and evaluated many mobile
> sites with a link at the bottom of the page that says "Desktop version"
> and it just serves up the same URL, without the breakpoint for mobile.

This is the point where we need to get technically accurate. There are 
various technologies in play here (and this is why generic terms like 
"mobile" only help muddy the waters):

- use of responsive layout with CSS media queries - these will trigger 
based on factors such as viewport/window width/height/pixel density; 
these are also triggered by zoom settings, window size, etc (so on a 
"desktop" machine, if i change my window size, or change my browser 
zoom, they will be triggered). as the browser handles the switching of 
layouts/styles, these sites will not have any kind of "switch to desktop 
version"

- use of JavaScript-based queries (either old-school checks of the 
windows's width/height, or more advanced uses such as 
window.matchMedia() 
https://developer.mozilla.org/en/docs/Web/API/Window/matchMedia which 
effectively allows the use of CSS Media Query syntax in JavaScript); 
these will also be triggered (depending on their specific logic) on 
desktop if browser window size is changed, user zooms, etc. These *may* 
provide some form of link or switch that effectively disabled the 
JavaScript logic responsible for doing the querying, but this is fairly 
uncommon to do

- server-side solutions which check the browser's User Agent string (UA 
sniffing) and, if it looks like it's a "mobile" device, generate 
completely different markup (under the same URL) for the user agent; 
these sites can, if the author has catered for it, have some form of 
link or switch to bypass the UA sniffing and serve/force the "desktop" view

Of these (there may even be subtle variations/combinations), only the 
last one can really be classed as an "alternate". The other two are all 
adaptations that happen directly on the client side, so count as a 
single page. All states of this page need to conform in order to pass WCAG.

> I have an action item to ask other old timers to WCAG their opinions.
> But here is my thinking. If the page has just ONE, WCAG conforming view,
> then it passed WCAG. Someone can claim conformance to WCAG and in their
> internal conformance statement say "accessibility supported for us means
> JAWS and IE, and a 22" desktop monitor". This stack meets the
> accessibility support requirements of WCAG. But they have met any law or
> judge that requires this site meet WCAG.

Then that is a problem to be tackled in the definition of "accessibility 
supported" https://www.w3.org/TR/WCAG20/#accessibility-supporteddef - by 
the same token, I could make a site that only works on a large screen 
and fails on a small desktop screen. Again, this is not mobile specific. 
If there's a hole in WCAG 2.x, it's a fundamental one that isn't just 
one of "mobile vs desktop" (and as was touched on elsewhere in the 
thread also extends to low vision, user customisation, etc).

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

Received on Thursday, 30 June 2016 17:02:29 UTC