Re: Request to re-open issue 131

Hi Rich,

Yes.

In my opinion, if an interactive canvas actually has a visually blinking
caret sitting there, it would be frustrating for me as a gecko
accessibility engineer not to be able to programmatically expose this caret
location to desktop clients and specifically to magnifiers (as you have
stated). For example on windows, if the canvas has DOM focus and there is a
caret drawn I would want to be able to call the system caret functions
(e.g. ::SetCaretPos). I don't really care what the web developer facing
canvas API is as long as I can ultimately get the x and y, height and
width. This is essentially item 1 in the details section of:
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection

Perhaps we could call the function "NaughtyMeSetCaretPos" :)

It seems like blink rate hasn't turned out to be controversial - ~500msecs
am I right?

Aside: for the record, in case there is any doubt, I want to say I too
won't advocate for canvas-as-text-editor usage in any form. However neither
would I paint C.P. a fool. I really appreciate the energy he, Steve, and
especially Rich have put into a problem for which so many are more easily
weary (myself included). I'm sorry to have not participated as effectively
as I had hoped (on canvas).

David

On Sun, Dec 18, 2011 at 6:28 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> I need the browser manufacturers to provide the tools to authors to allow
> the author of this application to help a magnifier vendor assist a low
> vision user in typing a text label for the drawing objects in this
> application without providing the caret position.
>
> http://www.canvasdemos.com/2010/08/05/lucidchart/
>
> Here is a real world use case. It is not a rich text editor. It is simply
> entering a text label for a drawing object. A canvas author can clearly use
> the canvas APIs to draw the text. All the browser manufacturers can use
> this. Why won't you let a low vision user with a magnifier do so? Maciej,
> Jonas, Ian, David Bolter, Ted please help me out here.
>
> We posted this application use case months ago.
>
> Rich
>
> [image: Inactive hide details for Charles Pritchard ---12/18/2011 01:07:41
> PM---On Dec 18, 2011, at 10:39 AM, Benjamin Hawkes-Lewis <bh]Charles
> Pritchard ---12/18/2011 01:07:41 PM---On Dec 18, 2011, at 10:39 AM,
> Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote: > On Sun, D
>
> From: Charles Pritchard <chuck@jumis.com>
> To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.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 01:07 PM
>
> Subject: Re: Request to re-open issue 131
> ------------------------------
>
>
>
>
> On Dec 18, 2011, at 10:39 AM, Benjamin Hawkes-Lewis <
> bhawkeslewis@googlemail.com> wrote:
>
> > On Sun, Dec 18, 2011 at 5:59 PM, Charles Pritchard <chuck@jumis.com>
> wrote:
> >> The HTML5 Editors draft uses scrollPathIntoView to accomplish the same
> thing as setCaretSelectionRect but with a broader goal and semantic. I've
> not been able to get its author to speak up on the issue...  They are both
> intended to fill in the caret tracking interfaces present at the OS level.
> These are used by zoom apps, but can also be used by heuristics in screen
> readers.
> >>
> >> The HTML5 editor did not use the caretBlinkRate semantic.
> >
> > Yes, likely influenced by implementor feedback. For example, Jonas
> > Sicking has already indicated his opposition to Gecko implementing
> > this:
> >
> > http://lists.w3.org/Archives/Public/public-html/2011Apr/0747.html
>
>
> The two objections difficulty of implementation and fingerprinting are put
> forward without proportionality. 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? I don't mean to rebut, I want to have a
> constructive conversation.
>
> 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.
>
>
> >
> >> If there are any ideas on how to salvage consensus on this maxFlashRate
> concept, it'd be nice to hear them. This is different than
> requestAnimationFrame use cases. This max flash rate is intended for
> on-screen position and progress indicators to help authors stay on the path
> to WCAG.
> >
> > 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.
>
> http://www.w3.org/WAI/WCAG20/quickref/#seizure
>
>
> 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.
>
> This kind of opaque implementation is in line with Mozilla's stance on
> pixel ratios with zoomed content. Something they only recently exposed
> through CSS selectors. Mozilla treats the pixel ratio (think browser zoom)
> as static in the JS environment whereas MS and WebKit do not. It's a
> position they have taken and I'm at peace with the doing the same here.
>
> I am not the right person to speak up for the blink rate proposal, but I
> hope I was able to share some more information about it.
>
> -Charles
>
>