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

Rich Schwerdtfeger
CTO Accessibility Software Group

Jonas Sicking <jonas@sicking.cc> wrote on 04/29/2011 12:42:23 PM:

> From: Jonas Sicking <jonas@sicking.cc>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: www-archive <www-archive@w3.org>, Sam Ruby <rubys@intertwingly.net>
> Date: 04/29/2011 12:43 PM
> Subject: 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.
>
Yes. Does Firefox support cookies? Cookies are vehicle for fingerprinting.
That is acceptable but blink rate is not? To me that says you are speaking
outside both sides of your face. The use of cookies is far worse for
fingerprinting than a user's blink rate.

> 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.
>

I am reading the following text from you:

> 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.

I am reading that you do not want to support carets/selection positioning
or blink rates.

I am quite sure Mozilla already accesses the Windows registry, Mac OSX
property files, etc. So, why is this a huge piece of engineering?

> 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.
>
My reading of the above statements is that you feel it is not worth the
effort to add caret tracking support as you do not feel it is not worth the
engineering time to support the work. Yet, authors have and continue to add
text editing features to canvas. So, people with limited or no vision would
be precluded from accessing these applications but you are I are not. So,
to me the only vehicle you have for discouraging this behavior is to
preclude people with these impairments from access. I am sure you have not
intended it that way but that is the what you are saying, whether you like
it or not.

> 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.
>
We have been fought on every issue to make canvas accessible from:

- caret tracking to selection position tracking because browser
manufacturers don't want to support rich text editing.
- blink rate exposure
- accessible sub tree (although there now)
- Clickable regions to support bounding rectangles
- text baseline

I think that about covers all of it.


> 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

I am asking if you are per:

> Apple, Microsoft, Google, Mozilla, are you going to implement the
> accessibility support for canvas and that include caret and
> selection tracking capability?

Rich

> 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 removed] 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