Re: Testability of Animation from interactions Issue 18

Hi Patrick

This is beginning to loop so I am signing off with this one.    You can have the last word.



You are only looking at this with a  first level of analysis.  

Read over the string of posts and you will see that while what you said is true - it is not relevant to the Flash discussion

the flash levels were set to be safe with 1024x768  15’ screen,  at normal viewing distance. 

All newer screens (mobile and large) have default pixel densities that result in smaller view angle - even if you hold mobile device closer to you.    So all of other instances you talk about would be SAFER  so it doesn't matter what newer screen (newer than 2008) you use at its typical viewing distance.  If you pass WCAG 2.0 using the Note2 dimensions (or the tool)  you will meet the SC with newer screens at the angle of view that is the definition of the criteria in the SC. 



RE the animation SC  —  I don’t think size has much to do with it.  Certainly things don’t need to be 1/3 of the screen in any dimension to cause the problems of distraction etc.     But I leave the animation work to the cog sc.  I have no new research beyond what we learned in doing WCAG 2.0 so I don’t have anything to say beyond the requirement in WCAG 2.0 that bans animation that lasts more than 5 seconds that doesnt have a way to turn it off. 



Thanks

Gregg


Gregg C Vanderheiden
greggvan@umd.edu



> On Jan 12, 2017, at 9:48 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> On 13/01/2017 02:01, Gregg C Vanderheiden wrote:
>> 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.
> 
> But as pointed out, the actual size of the stimulus on the user's retina can only be calculated correctly if you know the resolution of the screen in (CSS) pixels, the actual physical size of the screen, and the actual viewing distance. And as the last two can simply not be determined programmatically, and since they can and are very variable (even just for desktop, where people sit the same distance from screens that are actually quite different in physical size - something that gets even more complex once you take other devices like mobiles, tablets, phablets etc into account), it is not possible (even with a "tool", if that tool doesn't actually ask for physical dimensions/distances) to make an absolute determination for pass/fail. Any pass/fail is heavily reliant on the assumed/fixed value assigned to the physical screen size and viewing distance. So for instance, a pass (as determined using a "tool" or by manually calculating this) can still be a fail if the user, for instance, has a desktop monitor that is larger than the assumed average, still runs at the same CSS pixel resolution, while still sitting at the same distance...since that would result in the stimulus area being larger in real terms.
> 
> [...]
> 
>>> 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.
> 
> As a user, I can set my OS to drive the monitor at whatever resolution I want. Don't confuse physical pixels (individual hardware dots) with (CSS) pixels of what is displayed on your screen.
> 
>> All of the larger screens have higher pixel density — so the material
>> would be safer.
> 
> They have higher pixel density, but then the OS will use more physical pixels to display a single (CSS) pixel. In layman's terms, this is why on an iPhone with retina display things aren't half as big as on an old non-retina iPhone.
> 
>>> 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
> 
> No you won't. If the OS is still driving that physically larger display at 1024x768, it will be larger.
> 
>>> 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.
> 
> See above.
> 
>>> 
>>>> 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.
>> 
>> Correct
>> 
>>> 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).
>> 
>> Close
>> 
>>> 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
> 
> I think we'll have to disagree on this. Find me a random sample of web developers in the wild who would even begin to understand this measure, compared to saying "1/3 of the width by 1/3 of the height of the viewport/screen"
> 
>>> 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?
> 
> What I'm getting at is: since even the "tool" calculations make assumptions and essentially use constants for physical size of the screen and viewer distance to make their pass/fail determination (since the tool doesn't, from what you're saying, ask for these parameters), and since the only remaining variables that the tool can then work with is essentially a) the size of the area that's flashing and b) the overall size of the screen, why not simply define the measurement as a simple ratio of "if the flashing area is larger than 1/3 of the width by 1/3 of the height of the viewport/screen, it's a fail". This has the same uncertainty in terms of calculation that the current "steraradians..." measurement has, but is immediately more understandable. And this is also resolution-independent, as it's a percentage/ratio.
> 
>> 
>>> 
>>>>> 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 somewhere along the line this tool needs to be anchored on an assumption (since different displays, even of same physical size and at same viewing distance, can actually run at different resolutions). Is is basing its calculations on the reference pixel definition in CSS, perhaps? https://www.w3.org/TR/css3-values/#absolute-lengths
> 
> [...]
> 
>>> 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)
> 
> Again, there's a difference between pixel density in terms of hardware pixels of a display, and what (CSS) pixels are actually displayed.
> 
>>> (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.
> 
> But as you can't determine the actual size in real terms, because it depends on the physical screen size, the viewer distance, the resolution of the screen, something in that calculation must be anchored.
> 
> [...]
> 
>>> 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 distance...so 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. .
> 
> And once again, don't confuse physical pixels with logical/CSS pixels. My phone may be high resolution, but it's displaying standard web content at 320 pixels x 800ish pixels.
> 
> [...]
> 
>>> 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.
> 
> I'm pointing out that because all other variables are unknown/unknowable, they are being assumed/fixed, and that's why these are the only remaining variables that are and can be used for the calculation. YOU aren't saying that.
> 
> [...]
> 
>> Now that we are back to animation — I don’t think the size of the
>> animation has much to do with anything.
> 
> The proposed SC talks about "1/3 of the webpage view", so I thought it *was* relevant (before we took a detour into steraradians which led us down the conversation here). Surely a tiny animation that, in the extreme, only occupies one CSS pixel on the screen is less problematic than something that animates more than 1/3 of the visible viewport/screen, no?
> 
>> See the note at the top of the page.
> 
> Which page, which note?
> 
> 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 Friday, 13 January 2017 04:20:09 UTC