- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 14 Jan 2016 22:24:54 +0000
- To: public-mobile-a11y-tf@w3.org
On 14/01/2016 19:53, ALAN SMITH wrote: > So, is it our assumption that it is the responsibility of the typical > user - who may not know how (or even be able to see and read the various > instructions as to how) – to change all the settings in order to make > this usable and accessible. If the system itself is so ridiculously misconfigured by default that the OS itself, browser UI, etc are unusable, surely whether or not web content in a page they visit is not usable/accessible is the least of the user's worries? > Or, is it the developer’s and manufacturers’ responsibility to provide a > usable and accessible solution? I would say so, yes. Either way, it can't be the responsibility of the web content developer, as they have no way of controlling this or even querying this with any kind of reliability, if at all. There is no mechanism from JS to access "what is the actual physical screen size of this device" type information. All you can get at in JS and CSS are the CSS pixels reported by the browser. Making it the responsibility of *content* authors to also recognise and handle misconfigured systems would create an SC that is simply impossible for them to actually fulfil. Sure, in your case you *could* find out that the window/screen size is reported as 3200x1800 pixels, and from that potentially infer that it's a misconfigured machine and you should bump all your control sizes up. But who's to say that this wasn't actually a huge 50" display that the user sits in front of? Or a giant touch-enabled table (like a Microsoft PixelSense https://en.wikipedia.org/wiki/Microsoft_PixelSense)? In these cases your assumptions and corrections would swing too far the opposite way and make controls too large instead. 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, 14 January 2016 22:25:13 UTC