- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 22 Dec 2011 12:23:48 -0600
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Charles Pritchard <chuck@jumis.com>, Cynthia Shelly <cyns@microsoft.com>, david bolter <david.bolter@gmail.com>, "dbolter@mozilla.com" <dbolter@mozilla.com>, Steve Faulkner <faulkner.steve@gmail.com>, "franko@microsoft.com" <franko@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, Sam Ruby <rubys@intertwingly.net>
- Message-ID: <OF84477C15.F1B44104-ON8625796E.0064E633-8625796E.00650E77@us.ibm.com>
blink rate is not a screen reader issue. Consequently, screenwriter heuristics will not help. From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> To: Charles Pritchard <chuck@jumis.com>, Cc: Steve Faulkner <faulkner.steve@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Sam Ruby <rubys@intertwingly.net>, david bolter <david.bolter@gmail.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Cynthia Shelly <cyns@microsoft.com>, "dbolter@mozilla.com" <dbolter@mozilla.com>, "franko@microsoft.com" <franko@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org> Date: 12/18/2011 03:08 PM Subject: Re: Request to re-open issue 131 On Sun, Dec 18, 2011 at 7:06 PM, Charles Pritchard <chuck@jumis.com> wrote: > The blink rate getter for platforms that have it is a trivial task. Jonas suggests otherwise. How do we talk about a disagreement like that? Well you could provide evidence about its triviality rather than making assertions. Even establishing whether a platform has such a getter is part of the task. Does Android have one? I looked and asked before: http://lists.w3.org/Archives/Public/public-html/2011Apr/0736.html Windows has GetCaretBlinkTime: http://msdn.microsoft.com/en-us/library/windows/desktop/ms648401 (v=vs.85).aspx Apple Cocoa has an undocumented per-application "NSTextInsertionPointBlinkPeriod" configuration property: http://hintsforums.macworld.com/archive/index.php/t-63718.html It's not clear that's there's any way to get at some sort of system-wide setting. GTK has some documented configuration settings that can be queried: http://www.gtk.org/api/2.6/gtk/GtkSettings.html#GtkSettings--gtk-cursor-blink http://www.gtk.org/api/2.6/gtk/GtkSettings.html#GtkSettings--gtk-cursor-blink-time QT has a cursorFlashTime property on QApplication: http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#id-c2df98d1-409c-4bcd-ac65-b3eb4f2b6c55 Interestingly, Firefox already knows about a caret blink rate in the form of the undocumented ui.caretBlinkTime setting in about:config: http://www.jurta.org/en/prog/noblink If not explicitly set, it either uses a default or queries the underlying system. If I'm reading the source right: * For Windows it uses GetCaretBlinkTime: http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsLookAndFeel.cpp#340 * For Apple Cocoa it uses a hardcoded value 567 ms: http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsLookAndFeel.mm#319 * For GTK it spelunks inside gtk_settings: http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsLookAndFeel.cpp#417 * For QT it uses a hardcoded value 500 ms: http://mxr.mozilla.org/mozilla-central/source/widget/src/qt/nsLookAndFeel.cpp#356 * For Android it uses a hardcoded value 500 ms: http://mxr.mozilla.org/mozilla-central/source/widget/src/android/nsLookAndFeel.cpp#386 WebKit's source has a similar concept in the form of WebCore::RenderTheme::caretBlinkInterval, defaulting to 500 ms: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderTheme.h#L160 Only in the case of Windows does it actually query the underlying platform, again using GetCaretBlinkTime: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderThemeChromiumWin.cpp#L225 > As for fingerprinting, it's true that a blink rate API may expose that some users maybe running a popular AT screen reader. It's also the case that users of screen readers may benefit from the functionality. There are many many methods if fingerprinting, cache hit detection amongst the best examples. They are tolerated and somewhat reasonable when they exist as part of a purpose. The blink rate settings have a purpose for the minority of users that have adjusted them. It is not the case that browsers will implement anything that allows fingerprinting so long as someone can think of a purpose for them. Cacheing has far-reaching advantages that blink rate exposure does not (q.v. REST). A browser that did not cache content would be at a significant market disadvantage to one that did not. This is also true of a lot of legacy features that can be used to leak information, like cookies, as Jonas mentioned before: http://lists.w3.org/Archives/Public/www-archive/2011Apr/0096.html >> Aryeh Gregor has suggested: >> >> "It seems like a small enough loss >> for canvas cursors to not respect user blink rate settings, but if >> it's not, could you work out some API that lets authors honor them >> without knowing them? I.e., let the author say "I want this to blink >> at the user's blink rate setting", without letting them know what it" >> >> http://lists.w3.org/Archives/Public/public-html/2011Apr/0770.html >> >> This is more complex to spec, but perhaps more likely to win acceptance. > > > I know I've had a difficult time with the "use case" system. I'm not the author behind the blink rate proposal. I believe the primary intent of the proposal is for WCAG first, then for AT screen reader heuristics. Is this sentence a response to Aryeh's suggestion? > I have no problem meeting that WCAG section without the API... Though I'd not be picking up on the system settings put forward by screen readers. Anyway... Afaik, Richard was fine with the blink rate returning a static 500ms in browsers. * I don't think it's safe for authors to display flashing content higher than that suggested by WCAG, regardless of what caretBlinkRate reports. (I don't think it's a good idea to cause epileptic fits in public libraries, Times Square displays, etc.) * If in practice, implementors choose to return a static 500ms in all cases, then authors might as well have just followed WCAG's advice in the first place. I'm not clear what caretBlinkRate has to do with "screen reader heuristics". I believe the original intent was that hand-drawn carets - which are presumably only needed for text editing - should be drawn with an appropriate blink rate if the user has set one. I don't see why Aryeh's suggestion couldn't be made to work for this. -- Benjamin Hawkes-Lewis
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 22 December 2011 18:25:42 UTC