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

On Fri, Apr 29, 2011 at 11:10 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>
> 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.

First off, I recommend that you read the other replies in this thread
about fingerprinting as they explain the relationship between
fingerprinting and cookies. The gist of it is that browsers are aware
that the set of cookies the user has is something that identifies
him/her on the web. Thus the browser can manage that identity, for
example using features like private browsing. Statistical
fingerprinting however, is not something we can manage.

Second, cookies were invented a long time ago, way before anyone had
privacy on the web in mind. If we were to design them today we'd do it
significantly differently. We're going through great pains to try to
fix them now without breaking the web to the extent that no-one would
use our browser.

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

You are reading wrong. No where in that email am I talking about
selection positioning. Only caret blink rate. And in the other email I
sent shortly after I'm even discussion adding *more* APIs to manage
selections and focus. Turns out that what I was proposing is what you
had already proposed.

I'd appreciate if you read my emails before throwing pretty grave
accusations at me.

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

Again, I doubt that anyone has said that they don't want accessible
canvas. All the debates I have seen has been about how to archive
accessibility. Designing good features for the web is hard. Reasonable
people will disagree how to do it. I think that I can safely say that
for every single web feature I've seen designed, people have disagreed
on how to do it. That doesn't mean that people have different goals,
just that they have different opinions on how to reach them.
Accessibility is no different in this regard.

I feel that it's very unfortunate that you are insisting on
interpreting me (and apparently people on the whatwg list) in the
worst possible way. The web will suffer from it.

/ Jonas

Received on Friday, 29 April 2011 18:48:44 UTC