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

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



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