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

Richard,

I will send a technical reply on list as well, but I really don't appreciate
the contents of the below email.

You start out by accusing me of "speaking out of both sides of [my] mouth".
I have no idea what this accusation is based on? If you really truly believe
that is the case, then you better provide more to substantiate this
accusation.

Next you're putting up straw men: "leaving canvas without the ability to
enter *any* text accessibly is unacceptable". Surely canvas text
accessibility doesn't stand and fall with the ability to use the exact same
blink rate as the platform. The only result of not having access to the
platform blink rate is having to draw a cursor which blinks at a different
speed than the platform. This is at worst an annoyance to the user. I'm not
even sure that this is a accessibility issue *at all*, but I could very well
be wrong on that. Explanations appreciated.

To follow that up you accuse me of "using people with a disability as a tool
to achieve the goal". This claim is again wholly unsubstantiated and quite
insulting.

This accusation comes up again later: "all attempts to make [canvas]
accessible have been fought by WhatWG members". I strongly doubt that anyone
in whatwg has been fighting the idea of making canvas accessible. What I can
believe is that there are differences in opinion about how to make canvas
accessible. But that is not the picture you are painting.

Later you say "If browser manufacturers are not going to implement the
accessibility features that we have set down and do not work with us to fill
the remaining gaps..." which again is a straw man. Can you point to any
emails saying that browser manufacturers won't implement canvas
accessibility features in general? Or that we won't work with you to fill
gaps in canvas accessibility?

/ Jonas

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.
> - 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.
> - 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.
>
> 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 have burned a lot of hours on the canvas accessibility issue. Canvas was
> created and deployed as an inaccessible solution to the W3C. Accessibility
> was not considered in its design and all attempts to make it accessible have
> been fought by WhatWG members. Also, the creators of it have been more or
> less absent in the accessibility discussions. Canvas is the closest thing to
> what developers are familiar with on Windows which today is the pervasive
> client platform. If canvas is in the specification it will be used
> extensively and this leaves HTML itself inaccessible.
>
> I have a business need to address SVG accessibility and frankly, in private
> discussions, the browser manufacturers would prefer that people use SVG over
> canvas. If browser manufacturers are not going to implement the
> accessibility features that we have set down and do not work with us to fill
> the remaining gaps my recommendation is that canvas be removed from the
> specification. This is also what I will be telling IBM customers. I will
> also tell them that the reason it is inaccessible is because the browser
> manufacturers refused to make it accessible and not because it was
> technically impossible.
>
> Apple, Microsoft, Google, Mozilla, are you going to implement the
> accessibility support for canvas and that include caret and selection
> tracking capability? ... and don't give me a political response please like:
>
> - We don't announce our release plans
> - We are unable to answer at this time
>
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> [image: Inactive hide details for Jonas Sicking ---04/28/2011 09:34:34
> PM---Hi WG and WG Charis, I have some new information that I thi]Jonas
> Sicking ---04/28/2011 09:34:34 PM---Hi WG and WG Charis, I have some new
> information that I think is relevant to this decision.
>
> From: Jonas Sicking <jonas@sicking.cc>
> To: Maciej Stachowiak <mjs@apple.com>, Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc: HTMLWG WG <public-html@w3.org>
> Date: 04/28/2011 09:34 PM
> Subject: Re: Working Group Decision on ISSUE-131 caret-location-api
> ------------------------------
>
>
>
> Hi WG and WG Charis,
>
> I have some new information that I think is relevant to this decision.
>
> Specifically, this decision calls for adding a feature which allows a
> webpage to ask the UA for the cursor blink period of the platform that
> the user is currently using. This API has two problems:
>
> A) This is a actively harmful API in that it allows fingerprinting the
> user. I.e. a webpage could use this information, in combination with a
> lot of other information to with high statistical probability identify
> a user. There are already many such APIs, however several browser
> vendors are going through great pain to try to remove such APIs as to
> reduce the ability to fingerprint a user.
>
> B) I don't think it will be possible to get all commonly used browsers
> to implement this feature. Specifically, I think it's unlikely that
> we'd implement it in Firefox. This for the following reasons:
>
> 1. I don't want people to write text editors using canvas. They are
> bound to get a lot of things resulting in worse user experience for
> users. *Especially* for users that use AT.
> 2. It's not worth the engineering time needed. Weeding through the
> various platform APIs on which firefox runs to try to get at this
> information is non-trivial. The time could be spent on features that
> help users more.
> 3. The fact that it can be used for fingerprinting as described in A
> above. Especially given that the value of the API is relatively low.
> At worst the cursor would blink at a different rate on some webpages
> compared to elsewhere in the users environment. This isn't a loss of
> functionality or usability. At the most it is an annoyance. So the
> privacy-cost vs. value ratio is very bad here.
>
> If this new API is still added to the spec, we'd likely make firefox
> always return 500ms or some similar constant as this removes the
> ability to fingerprint, while still allowing the page to work. However
> before that we'd likely hold off implementing the feature completely
> and hope that it's removed from future drafts.
>
> Note that as usual, I'm not speaking for all of the mozilla project.
> However I am speaking as someone that works a lot on our scripting
> APIs, as well as someone that takes part in a lot of our security and
> privacy reviews.
>
> / Jonas
>
>