Re: Testability of Animation from interactions Issue 18

On 10/01/2017 23:14, Gregg C Vanderheiden wrote:
> Gregg C Vanderheiden
>> On Jan 10, 2017, at 6:04 PM, Patrick H. Lauke <> wrote:
>> On 10/01/2017 22:55, Gregg C Vanderheiden wrote:
>>> 2) I agree with Patrick that 10 degrees of visual field won’t work
>>> 1. you can’t calculate that unless you know  a) how far the person is
>>>    from the screen   b) the size of the screen  and c) the pixel
>>>    resolution of the screen d) the scaling of the screen.   None of
>>>    these are known to the author and change from user to user
>>> 2. (Most people couldn’t calculate it if they did know those things)
>> Related to this, is there any chance the definition "general flash and red flash thresholds" currently in WCAG 2.0 can also be somehow changed/simplified for 2.1 according to whatever is decided here, as it presents exactly the same problems?
> That one is worse and also has 40% in the middle.  But that is what the research base is for it was.   But there is a tool that automatically does the analysis for you — so that is not a problem.
> Perhaps making a test tool for this one would help as well.

I'm failing to see why the "33% of any 10 degree visual field on the
screen" has the issues (1 and 2) you noted, but the existing ".006 
steradians within any 10 degree visual field on the screen (25% of any 
10 degree visual field on the screen) " from WCAG 2.0's current 
definition for general flash and red flash thresholds doesn't?

Does "visual field on the screen" not, in essence, mean the full size of 
the screen/viewport? And if not, isn't the general flash/red flash 
definition not also fundamentally flawed as it can't take into account 
physical screen size / viewing distance / etc, regardless of the 
existence of a "tool"?

>>> 3) You can’t use 1/3 of web page because
>>> 1. a web page could be 500 ‘pages’ long so nothing would be 1/3 of it.

not 1/3 of the *web page*, but 1/3 of the viewport size (e.g. on most 
smartphones, for a page that sets a mobile-friendly ideal viewport with 
a width=device-width meta viewport directive, around 320 x 600 density 
independent CSS pixels).

>>> 2. and you can’t use 1/3 of screen for the same reason as #2 above.

You could if you take at least the assumption that a user will position 
themselves in a way that they can comfortably see the entirety of the 
screen/viewport, so that it takes up their field of vision. That won't 
be true everywhere, of course, but without any form of base assumption 
like that, I don't think we can have ANY anchor points (this echoes 
pretty much the discussion about not being able to determine physical 
size of something rendered on a screen, combined now with a further 
unknown variable of viewer distance)

>>> 4)  I THINK — Doing it in CSS pixels (aka David) is the best bet but
>>> remember that a large blinking “O" only changes a relatively small
>>> number of pixels -- so you might look at pixel area rather than pixels.
>> What about simply percentage of overall screen/viewport size? It's still an approximation, as some users will be closer/further away from their screen so even the full screen/viewport will in fact occupy different angle of their full field of view, but it's at least something that can be consistently queried and tested (though in context of responsive design, it'll need to be tested for each breakpoint/common device screen resolution). for instance, simply saying "more than 1/4 of the viewport" or similar?
> Same problem as above.  You have absolutely no idea how large that is without knowing a bunch of things about the screen (see #2 above)
> however — you might do something like base it on a typical screen size and resolution and scaling etc — and then set your threshold there.      This was done for Flash.

There is no single "typical screen size". At best, we can hope to define 
10 or so "typical screen sizes" for small smartphones, medium 
smartphones, large smartphones, small tablets, medium tablets, large 
tablets, small laptop/desktop screen, etc.

Patrick H. Lauke | |
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 10 January 2017 23:46:58 UTC