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

Exactly.   

That is why the ability to personalize is so important.  That is one more example of the fact that  "one size fits all" doesn’t work - even for a single disability - much less for everyone. 

Gregg
--------------------------------------------------------
 
On Sep 11, 2013, at 10:06 AM, Peter Korn <peter.korn@oracle.com> wrote:

> Gregg,
> 
> Your thoughts are very similar to mine.  The key, I think, is having a configuration setting to turn off caret/cursor blinking.  Note: doing so may make it more difficult to locate the focus (e.g. when focus is indicated in an edit-text field solely by the presence of a blinking insertion point).  But 2.4.7 Focus Visible says: "...has a mode of operation where the keyboard focus indicator is visible".  This shows the brilliance of the folks developing WCAG.
> 
> There is no requirement in WCAG that states that you must BOTH have no blinking AND at the same time make the focus visible.  Mind you, various accessibility regulatory efforts push for addressing multiple disabilities at the same time in ways that might be difficult to satisfy.  But then, we know already that solutions for some users some cognitive disabilities can actually make things worse for other users with other, different cognitive disabilities...
> 
> 
> Regards,
> 
> Peter
> 
> On 9/11/2013 5:57 AM, Gregg Vanderheiden wrote:
>> [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
>> 
> 
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment