Re: Conforming alternative for mobile should not be Desktop

Wow, I didn’t expect to get up this morning to a 40+ email WCAG thread! Seems like a case of violent agreement in general with some terminology differences.



For brevity:

- I agree with David’s aim.

- I agree with Patrick’s arguments on terminology.

- I wrote quite a bit, but the last couple of emails resolved most things so I’ve deleted most of it.



TL;DR: Should we add something to the accessibility supported section (or somewhere) to make it clear that we have to assume people may only have access to small-screen/touch devices?





David wrote:

“It seems to me this position effectively turns our Mobile task force work into a "nice to have" set of advice, that can be avoided if the author simply provides a link to the conforming desktop site. Can you explain to me how that is not true?”



Apart from terminology, the potential scenarios also seem confusing. A site might have a responsive site, or a mobile & desktop approach, or a hybrid approach. We’ve only got one client with a mobile & desktop site approach, and they are regretting that now.



However, I’ll assume there are sites with a mobile & desktop approach where the (old) desktop site is accessible(ish) and the mobile one isn’t.



Firstly, I don’t think that many (or any) sites will want to use a mobile / responsive site and desktop site long term, that doesn’t make sense except in a transition to responsive [1]. (Although they might have responsive + AMP + facebook instant article versions. Has anyone considered the webpage via an app scenario?)



You could see a link from a mobile site to desktop version as a loophole which significantly decreases the experience for some people, however, I think that’s a diminishing scenario. Even if it weren’t, I think desktop sites would rarely meet WCAG, especially once we get to 2.1.



The point we often have to make to clients is that people may have to use small-screen / touch devices (SSTs?) as their only access.



I think Patrick’s proposed addition makes sense, and perhaps we could add a line in the ‘accessibility supported’ text to deal with this assumption? I.e. accessibility supported should include various devices, it doesn’t just mean traditional desktop access.



This issue applies as much to professional accessibility testers, we need to make it clear that we should test “desktop” sites with mobile UAs, regardless of client assumptions. (We generally say that we test to the standards, rather than with particular UAs. However, you could miss some things if you don’t know how SSTs work differently so depending on the site setup we will check.)



Cheers,



-Alastair



1] Based on vicarious experience of how expensive it is to keep separate sites running, and that browser support for responsive layout and images are improving to the point where there is little upside to running separate sites.