Re: Request to re-open issue 131

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



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