Re: Working Group Decision on ISSUE-131 caret-location-api

On Fri, Apr 29, 2011 at 7:06 AM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

>  Jonas,
>
> First, let me start out by saying you have been a tremendous supporter of
> accessibility at Mozilla, but at this point your comments lead us on a path
> that leaves canvas inaccessible.
>
> - I don't buy this fingerprinting argument at all. Hard coding the blink
> rate does not reflect the user's settings. Frankly, it is a ridiculous waste
> of resources on behalf of the browser vendor to have to put in a constant
> for a blink rate when an author can define the constant themselves to be
> WCAG 2 compliant. Cookies do far more damage with respect to fingerprinting
> than this will, yet they still are used extensively and are not prohibited
> by browser manufacturers ( not everyone knows to turn on private browsing).
> Frankly, I see this as the browser manufacturers speaking out of both sides
> of their mouth.
>
Others have explained fingerprinting, so I won't.

However it seems like you are saying that authors can use a constant blink
rate to be WCAG 2 compliant? Then why would it be a problem if the browser
returned that same constant? Or even simpler (both for browsers and for web
pages), if the page just embedded that constant in the code directly?

> - I agree with you that canvas is not the right tool for rich text editing
> but leaving canvas without the ability to enter *any* text accessibly is
> unacceptable. There is no way we can clearly delineate the need to enter
> text in canvas from HTML in all situations without making a horribly ugly
> user experience. Consequently developers will introduce their own text
> editing and frankly most could care less about IMEs. Removing the ability to
> support accessibility will not deter many developers from providing the
> ability to enter text into a drawing object. You do not enforce good
> development practices by using people with a disability as a tool to achieve
> the goal.
>
Surely removing the ability to get the platform cursor blink rate
isn't "leaving
canvas without the ability to enter *any* text accessibly"?

I'm having a hard time even understanding how getting the accurate platform
blink rate is even a accessibility issue. It seems to me to be just an
annoyance for users that the caret in a particular webpage blinks at a
different rate than the caret elsewhere on the users platform.

The important part is that they do use a cursor and that that cursor blinks
at a reasonable rate, no?

>  - When I point to the need for clickable regions to represent where
> drawing objects are on canvas to support accessibility (Yes, the ATs,
> actually need to find them like us sighted people) someone says use SVG.
>
I don't know how this relates to my request to remove the API for getting
the platform blink rate?

>  We went down this path before with HTML and this resulted in the
> JavaScript accessibility problem which caused web accessibility compliance
> criteria that resulted in technology restrictions. This caused industry
> millions of dollars to fix. IBM alone gave an enormous contributions to
> Mozilla as part of the solution to fix that mess. I do not want a repeat of
> this debacle. It came at enormous cost to industry.
>
I honestly don't know what this is about. I assume it happened before I
worked at IBM and before I worked at Mozilla. If this is relevant to the
topic at hand it would be helpful with a link or a description.

However I do really appreciate the contributions that IBM has given both to
the mozilla project, and to netscape before that, over the past 17 or so
years (I'm not entirely sure when it started, so I might be off by a couple
of years).

/ Jonas