W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 29 Apr 2011 14:32:00 -0500
To: Jonas Sicking <jonas@sicking.cc>
Cc: Sam Ruby <rubys@intertwingly.net>, www-archive <www-archive@w3.org>
Message-ID: <OF7EEB9047.FFD1FD9E-ON86257881.006A5963-86257881.006B4D12@us.ibm.com>



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.

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

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

> / Jonas
Received on Friday, 29 April 2011 19:32:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT