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

On Fri, Apr 29, 2011 at 12:32 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> Jonas Sicking <jonas@sicking.cc> wrote on 04/29/2011 01:47:47 PM:
>
>> From: Jonas Sicking <jonas@sicking.cc>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: Sam Ruby <rubys@intertwingly.net>, www-archive <www-archive@w3.org>
>> Date: 04/29/2011 01:49 PM
>> Subject: 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.
>>
> I understand the issue but nobody is removing the problem and as I said not
> everyone pays attention to the private browsing features, especially
> seniors.

I have a hard time understanding what you are saying. Of course not
everyone cares about privacy, just like not everyone cares about
accessibility. How does that matter?

>> 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.
>>
> I understand that too. I really do understand all your justification for why
> you don't remove cookies. However, I do not think that blink rate comes
> should be elevated to the level of fingerprinting that is already allowed by
> cookies.

It's not, I never said it was. I'm just saying that i'm opposed to add
it to Firefox given that the value vs. cost ratio is so bad. Included
in that cost is the cost to privacy.

>> >> 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.
>>
> So, what is your position on implementing the canvas accessibility features?
>
> Jonas, I don't have time to keep working on canvas accessibility if all the
> work is going to go in the bit bucket. I just as soon remove canvas and work
> on SVG. Mozilla has been the lead implementer of the Web 2.0 accessibility
> work, like ARIA. If you don't want to do the work I don't see any reason in
> proceeding. We need your help.

I don't understand why you keep asking this? I have never said
anything about not wanting to implement any other accessibility
features. And you still haven't explained why cursor blink rate even
is an accessibility feature.

I understand if working on web features is frustrating, it is a lot of
work. We all put in a lot of effort, much of it wasted, some of it
not.

Yes, in general I'm for implementing accessiblity features in firefox.
As I am implementing other features. It's hard to give a stronger
statement than that given how generally you're asking the question.
I'm always opposed to generating bad features, even if they are bad
accessibility features.

I'm also strongly opposed getting accused in the manner you did in
your original email in this thread and which you still haven't
retracted any of.

/ Jonas

Received on Friday, 29 April 2011 20:30:00 UTC