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 03:29:02 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 03:33 PM
> Subject: 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?
>
I am simply saying that private browsing features are inadequate, in
eliminating the privacy issue.
I used seniors as an example.

> >> 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.
>
We could go back and forth on this forever.

How about we get back to the question of implementation. Will Mozilla
implement the canvas accessibility features proposed for caret/selection?


> >> >> 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
accessibilityfeatures?
> >
> > 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