Re: Testability of Animation from interactions Issue 18

In the Epilepsy FLASH - the size of the flashing object (in visual angle) is critical since its size relates to the area of the brain that is stimulated —and the larger the visual angle the greater chance it will cause a seizure. 
but it is the absolute size of the stimulus and it has nothing to do with the size stimulus in relation to the size of the screen.

For animation — I’m not sure the size is that important.  I think that even small animations can be very distracting (that is what we were told in WCAG 2.0 work ).     And the time of type of animation would also seem to be more important than its size.    A smaller flashing image would be much more distracting than a large slow moving image.   

Do we have any research on what animation is most distracting?    

By the way 

There is already a LEVEL A provision that says any animation  (of any size)  must last no more than 5 seconds or there must be a way to turn it off?    

Sorry to not know the answer —  but what is the provision being considered here that isnt covered by the current ban on all animation over 5 seconds?



Gregg C Vanderheiden

> On Jan 12, 2017, at 5:59 PM, Patrick H. Lauke <> wrote:
> On 12/01/2017 21:28, Gregg C Vanderheiden wrote:
>> Read my email, and WCAG glossary definitions.    I THINK all your
>> questions are answered there.
> [...]
>> yes it did have standardized measures.
>> No I don’t think it is questionable - because of the structure we
>> used.    if you start at a point and set a criterion that is safe
>> where all the variability goes toward more safe views.
> So the most relevant part of the definition for me is the following:
> "341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). (Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds.)"
> So roughly, this equates to a rectangle that has the dimensions of 1/3 of the width by 1/3 of the height of the viewport/screen.

This is correct. 

> What happens if any of the variables such as screen size or viewing distance change, but the rest remain the same?

The screen gets SAFER.

> What if it's a 24 inch screen at same resolution and viewing distance? (not uncommon nowadays for people to have much larger screens, but to still sit at the same desk/distance from the screen)
There are no 24 inch screens that are 1024 x 768.   

All of the larger screens have higher pixel density — so the material would be safer. 

> It would result in a rectangle that has the same pixel dimensions, but actually in physical terms it's rendered larger, so occupies a larger field area in the user's absolute field of view.
If you look at that same page on one of those screens you will find that the content is smaller  

> So there is already variability here in real terms, and it's the same sort of variability that we're discussing here, no?

Variability - yes.    But not less safe. 

>> the only thing not covered is if a person uses a magnifier on the
>> flashing element.    But that will fail no matter what you do and the
>> author can’t predict or address that anyway.
> The author also can't predict the actual physical size of the screen, nor the actual viewer's distance.


> So there are assumptions being made (about the "standard screen size and viewing distance"), and with those fixed, the only other remaining variable is screen resolution (in the example in the spec, 1024x768).


> So, boiling this down, it seems reasonable to say that really the highly obscure definition of ".006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen)”

that is the rule and it is not obscure in any sense of the word.  It is very specific.   It may be technical but not obscure.   And the notes make it concrete and easy to understand in people’s minds
> essentially comes down to (since 2 variables have been assumed as ideal/fixed) "1/3 of the width by 1/3 of the height of the viewport/screen". Or am I missing something?

This is confusing.    It is 1/3 of 1/3 of one particular size screen and resolution combination.    It is not 1/3 by 1/3 of anything else.   So I’m not sure what you are getting at.   Can you help me?

>>> Does the tool require you to enter the variables like physical
>>> screen size, viewing distance, etc? Or does it simply base its
>>> calculation on the screen/window size? If the latter, then it's
>>> doing nothing different from what I'm proposing, i.e. anchoring any
>>> measurement on viewport/screen size and writing out clearly what
>>> that ratio is.’
>> No,  If you read the whole email I think you will see that this is
>> covered.
> As above, the tool in that case assumes ideal/fixed conditions of physical screen size and viewing distance, I take it?

No.  Assumes that pixel density or a smaller pixel density. 

> So in essence simply calculates the ratio of the flashing area in relation to the whole screen size?

no - not true at all.    it is based on the visual angle. 

>>> So the answer is actually yes? i.e. "visual field on the screen" as
>>> a whole means the whole size of the viewport, and then of that you
>>> calculate a 10 degree angle portion? If so, then it is possible to
>>> rewrite the "10 degree visual field on the screen" into some
>>> relationship that's anchored on the size of the viewport?
>> No -  If you read it more carefully I think you will see why this is
>> not true.  at least not how it is used in the  FLASH SC.
> I have read it more carefully, but have come to the same effective conclusion...since physical screen size and viewer distance are assumed to be “ideal”
no not ‘ideal’.    that is just one data point.    Actually anything with higher pixel density is more ideal (safer)

> (along the same effective ratio as having a 15-17 inch screen at 22-26 inches distance), it stands to reason that the ratio IS only calculated based on the area of what's flashing versus the overall screen area, no?

No.   it is based only on the size of the area that is flashing.   Size of the overall screen has no effect at all.   your peripheral vision has  so few sensors and so little area in your brain as compared to your focal area that there is no real effect.   So screen size outside of the angle of view prescribed in the rule is not relevant.      At least that is what the researchers in this area found. 

>>>>>>> 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"?
>>>> Not flawed.  But it is subject to the same problems you are
>>>> talking about with this SC.   If you read the rest of the text
>>>> of the glossary definition you will see we addressed them by
>>>> assuming screen size, resolution, and viewing distance.  Since
>>>> (in this case) we are talking about things being a problem if
>>>> they are large— our assumptions were based on typical to older
>>>> screens — with newer screens creating less of a problem.  So
>>>> viewing the material on a higher resolution screen or on a mobile
>>>> device would alway be safer.
>>> But a mobile device screen is usually held closer to the viewer's
>>> eye, which in essence means that it occupies the same/similar
>>> overall visual field of a user as a larger monitor that's further
>>> away, no?
>> While that is true —  it is so much smaller that the distance
>> difference is completely overwhelmed by the size difference — and the
>> math still works out.   it is safer— so criteria is still met.
> If I hold my mobile phone at 3-4 inches from my eyes (which for certain activities, like watching a movie, I just might), it occupies roughly the same area of my field of view as my 24" monitor on my desk at the average viewing I would not say that's always a safe bet.

Yes you are correct - it would.  But it has many more pixels than the 1024/768 screen at 15 inches does.   so the pixels definition and the angle definition would both yield a save view for you.
  Do the calculations and you will see what I mean. .  

>>>> So our criteria resulted were based on research, were set to
>>>> accommodate most common and older tech at the time, and still
>>>> held (were safer) with newer and mobile screens.
>>> I think this may need a rethink, or at least a different anchoring,
>>> to make it more generally relevant in a world where screens come in
>>> all shapes and sizes, resolutions, and typical viewing distances.
>> The animation maybe - but the Photosensitive epilepsy provision still
>> works even as we invent more shapes and sizes and resolutions of
>> screens as long as we are viewing them at typical viewing distances
>> for the different shapes sizes and resolutions
> Both animation and photosensitive epilepsy are concerned with how much of the field of view the animation/flashing are taking up. So if, as discussed above, even for flash/red flash the measurement effectively boils down to a relationship of what's flashing in relation to the overall size of the screen

You keep saying that it is the flashing area in relation to overall screen size.  But no where did I say that — and it is absolutely not true.

> (since we have to assume physical size and viewing distance are fixed/ideal since we can't guarantee nor measure them anyway), I'd say it's sensible to use the same rationale for animation and define this as a ratio of the viewport (not web page size, but actual visible viewport)...and after doing that also simplifying the definition for general flash/red flash the same way and removing the obscure ".006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen)" measurement?

Now that we are back to animation — I don’t think the size of the animation has much to do with anything.

See the note at the top of the page. 

> P
> -- 
> Patrick H. Lauke
> <> | <>
> <> | <>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 13 January 2017 02:02:24 UTC