Re: Technolog Agnostic / Independent

Wayne Says:

>Screen size is so significant that SCs relating visual interface really
need a concept like "break point". Developers certainly do not treat mobile
phones like desktops. There are things you do not do on a small screen. Few
people write code on a mobile phone. People with low visual acuity will
probably read very little on a mobile phone. ... This construct could be
used for target size as well.

I agree with this sentiment. I realize there are strong opinions that there
is "no such thing as mobile", I think we could solve a lot more problems
than we'd create if we took this approach in this 2.1 version. Maybe in 5
years there will be accurate, elegant, well supported and well known
sniffing techniques for fine/coarse pointer types and user distance, but in
the meantime my preference would be to decide on a mobile break point and
provide some separate requirements (such as target size) if there are
breakpoints on the page. (Most sites these days have breakpoints)

Wayne, I agree with you.

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, Apr 10, 2017 at 1:50 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 10/04/2017 18:40, Wayne Dick wrote:
>
>> This 2.1 project has reached a breaking point for the old notion of one
>> SC for all technologies. The idea is not to drop technology
>> independence, but to expand it to fit things like geometric reality.
>>
>> Screen size is so significant that SCs relating visual interface really
>> need a concept like "break point". Developers certainly do not treat
>> mobile phones like desktops. There are things you do not do on a small
>> screen. Few people write code on a mobile phone. People with low visual
>> acuity will probably read very little on a mobile phone.
>>
>> It does not make sense to treat tiny screens like big screens when we
>> are discussing visual accessibility. We need a concept like "technology
>> agnostic where appropriate". Or a concept like break points for size.
>>
>> Consider font size. There are two factors to consider. Screen size S and
>> viewing distance D. If font size of s at distance d that is sufficient
>> then 3/4(s) at 3/4(d) will also be sufficient.  So we need a break down
>> for testable prescriptions:
>>
>> Screen Size    Viewing Distance    Font-Size % of Height/Width
>> s0 to s1          d0 to d1                f1
>> s[n-1] to s[n] d[n-1] to d[n]         fn
>>
>> Note that the Font-Size percent can be computed using pixels using
>> breaks points.
>>
>
> The problem here being that web content authors have no way to determine:
>
> a) physical dimensions of a screen
> b) viewing distance that the user may be at
>
> Which is why the only good approximation we can rely on are CSS pixel
> dimensions (of the viewport) when the device is rendering content in
> whatever the device's "ideal viewport" is (in HTML terms, the size that
> things are rendered at in the browser when the meta viewport is set to
> width=device-width).
>
> This ideal viewport is what the device manufacturer and user agent have
> determined would be the "best" resolution for their particular
> device/environment and general use. (since device manufacturers and native
> user agents *can* either know the actual physical dimensions of the device
> and the average viewing distance of the user a priori, or can query certain
> device metrics not exposed to web content/JavaScript).
>
> 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
>
>