Re: A question has come up about SC 2.2.2 & the blinking caret/cursor...

> it sounds like you’re saying that the Flash criteria apply to blinking 


It does and but you would always pass it. 

TECHNICALLY
the Flash provisions (and all provisions) apply to everything.  Including a blank page.   
The question isn't whether they apply or not -- but whether the page PASSES or SATISFIES the success criterion. 

So back to the cursor question
- to fail -
FIRST - something would have to flash or blink or whatever, more than 3 times in a one second period.
I have never seen a cursor flash that fast.   but I guess it is possible
SECOND - something that flashes more than three times in 1 second has to ALSO be large enough to cover 40% of your central visual field.     This is pretty big.    Much larger than any cursor.    So SC 2.3.1 would apply but you couldn’t fail SC 2.3.1  with any non-magnified cursors -- even large ones. 



> I agree that the key issue seems to be that this blinking can be stopped somehow or that there are user agents available which don’t have the blinking behavior.

Right 

>  
> Thanks,
> AWK





Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering University of Wisconsin-Madison
Technical Director - Cloud4all Project - http://Cloud4all.info
Co-Director, Raising the Floor - International - http://Raisingthefloor.org
and the Global Public Inclusive Infrastructure Project -  http://GPII.net

On Sep 11, 2013, at 11:17 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:

> Also not speaking for the WG, but it sounds like you’re saying that the Flash criteria apply to blinking and I don’t read it that way.  The note in the blink definition says:
>  
> Note: See also flash. It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash.
>  
> I agree that the key issue seems to be that this blinking can be stopped somehow or that there are user agents available which don’t have the blinking behavior.
>  
> Thanks,
> AWK
>  
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>  
> akirkpat@adobe.com
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>  
> From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] 
> Sent: Wednesday, September 11, 2013 8:58 AM
> To: Peter Korn
> Cc: public-wcag2ict-tf@w3.org
> Subject: Re: A question has come up about SC 2.2.2 & the blinking caret/cursor...
>  
> [The comments below are my opinion - and not official findings of WCAG WG.    Gregg Van - ex co-chair of WCAG WG]
>  
> The caret would never be a problem with 2.3.1. since a)  it would have to  blink more than 3 times in any one second period (which I have never seen) or else it automatically passes  and  b) it would have to occupy more than 40% of the area subtended by the eye (10 degrees) -- as normally displayed on a 1024 x 768    15 inch screen.  (See definition in WCAG 2.0).     So you are correct Peter - a blinking text caret/cursor would never fail 2.3.1 with any caret that I have ever seen or could imagine -- even if you did create one that blinked more than 3 times a second (which would drive me to distraction). 
>  
>  
>  However -- one of the reason for the provision, is that blinking content can be a distraction for some people that prevents them from focusing.   And small blinking objects can do this as well as large.  In fact the reason the cursor blinks is specifically so that it will catch your eye.
>  
> The normal way to solve this is  to provide a way for the cursor to be made to not blink.  A non-blinking cursor option.   
>  
> NOTE: if the blinking cursor is part of the browser (and not actually something created, and blinked, by the web page content) then it is up to the browser not the web page to provide the non-blinking option.    
>  
> For software it is a bit different I think. If the system cursor blinks, and it is known that there is no option to turn it off, the preferences/settings of the application could provide such an option.  Clearly however, the place that this should be fixed is by providing a non-blinking cursor option in the system control panel -- where other cursor options are provided.  
>  
> In the case you cite (the terminal window) it is not clear what kind of terminal you mean - or whether this is a (terminal) application generated cursor or a system cursor.   But the above would apply. 
>  
> And finally, yes - I think that something to this effect should be in understanding doc -- at least for web pages.     Not sure we can say much about software in the Understanding WCAG 2.0 -- but something like about the OS could be. 
>  
> Maybe something like 
>  
> "Note: a blinking text caret/cursor is specifically designed to catch the attention of the user, and would fall under this provision. However, if the caret/cursor is not generated by the content, but if it is a system or browser generated cursor, it is the browser or system that should provide the option to turn it off so that it does not blink for the user on all pages (or applications). "
>  
>  
> Gregg Van
>  
>  
>  
>   
> From: Peter Korn [mailto:peter.korn@oracle.com] 
> Sent: Tuesday, September 10, 2013 10:18 PM
> To: public-wcag2ict-tf@w3.org
> Subject: A question has come up about SC 2.2.2 & the blinking caret/cursor...
>  
> Hi gang,
> 
> As we are digesting WCAG2ICT's guidance internally at Oracle, a question came up about whether and how SC 2.2.2: Pause, Stop, Hide should be applied to the blinking text caret/cursor in a terminal window (or the actual machine console).
> 
> We presume that the blinking text caret/cursor is too small a blinking/flashing region to trigger 2.3.1 Three Flashes or Below Threshold, but that is addressing a different concern.
> 
> 
> Should a blinking text caret/cursor be a violation of 2.2.2?  Or is what is blinking not "information"?  Or is the blinking "essential"?  Or is perhaps the blinking area small enough that it doesn't serve as a significant distraction (since it's not a problem on a console for a console screen reader or magnifier), that we might appropriately add language to Understanding to essentially exempt that behavior?
> 
> 
> Regards,
> 
> Peter
> -- 
> <image001.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <image002.gif>Oracle is committed to developing practices and products that help protect the environment