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

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 
<http://www.w3.org/TR/WCAG20/#navigation-mechanisms-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 <http://oracle.com>]
>> *Sent:*Tuesday, September 10, 2013 10:18 PM
>> *To:*public-wcag2ict-tf@w3.org <mailto: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 howSC 2.2.2: Pause, Stop, Hide 
>> <http://www.w3.org/TR/wcag2ict/#time-limits-pause>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 trigger2.3.1 Three Flashes or Below 
>> Threshold <http://www.w3.org/TR/wcag2ict/#seizure-does-not-violate>, 
>> 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> <http://www.oracle.com>
>> Peter Korn | Accessibility Principal
>> Phone:+1 650 5069522 <tel:+1%20650%205069522>
>> 500 Oracle Parkway | Redwood City, CA 94065
>> <image002.gif> <http://www.oracle.com/commitment>Oracle is committed 
>> to developing practices and products that help protect the environment
>

-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment