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

On Fri, Apr 29, 2011 at 3:06 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> - I don't buy this fingerprinting argument at all.

I refer you again to:

http://panopticlick.eff.org/self-defense.php

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

Coding a WCAG2-compliant default in popular browsers requires perhaps,
what, 10 developers?

Coding a default in client web code instead requires hundreds of
developers.

Therefore, coding a default in browsers is less of a waste of resources.

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

Conforming HTML5 UAs are allowed to restrict cookies; and in practice
browsers give users the option to do so.

The Change Proposal text did not allow conforming UAs to restrict blink
rate leakage; neither does Hixie's patch.

It's not viable to argue the world does not need privacy safeguards
because people are careless with their privacy. It's not even viable to
argue that people will be proportional in their risk assessments.

@ping, an HTML5 feature premised on the ubiquity of tracking and
which included provision for users disabling it, nevertheless attracted
a degree of user hostility when briefly implemented in Firefox.

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

As far as I can see, the really hard problems for authors and
implementors are imposed by canvas text editing generally not rich text
editing in particular.

What do you think is the significant extra work needed to support rich
text editing that is not already needed to support plain text editing?

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

What makes you convinced that mashing up <canvas> elements and
@contenteditable elements would lead to a more ugly user experience than
existing typical canvas apps, such as Lucid Charts, that mash up
<canvas> elements and <div> elements?

> Consequently developers will introduce their own text editing and
> frankly most could care less about IMEs.

I fear the set of developers that don't care about internationalization
has a lot of overlap with the set of developers that don't care about
accessibility. I think both these aspects of software quality involve
an enthusiasm for human differences and/or an ambition for business
on a big scale.

> You do not enforce good development practices by using people with a
> disability as a tool to achieve the goal.

Sure, but your rhetoric confuses "using people with a disability as a
tool" with spending cycles providing developers with better tools, such
as improving SVG and @contenteditable, that serve people with
disabilities better as a side-effect.

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

Indeed, because SVG is designed to solve this sort of problem.

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

This is a dubious analogy.

HTML4 alone did not provide the functionality to create the user
interfaces people wanted to create. HTML4 plus JS did. So developers
used HTML4 plus JS.

But in this case SVG appears to provide the functionality to create the
user interfaces people want to create. Most of the example applications
are diagramming applications of various sorts, which makes them clear
candidates for writing in SVG. The Bespin project, which is the obvious
poster child for canvas inaccessibility, ultimately abandoned the direct
draw approach in favour of DOM.

There may be aspects of the APIs for canvas that developers prefer
over the APIs for SVG. It may be that the additional complexity required
to make canvas text editing accessible will outweigh that preference.
Conversely, it may be that we could write APIs for SVG that developers
would prefer even over canvas!

In practice, when asked why they were using canvas instead of SVG,
developers mention things like bugs in SVG implementations or slowness
in DOM manipulation. Bugs can be fixed. Conversely, sub-DOM
manipulation, accessibility tree manipulation, and a retained mode to
support canvas accessibility might well eliminate any performance
benefits to picking canvas. I've often seen accessibility sacrificed on
the altar of performance, so I don't think this is an idle concern.

> Accessibility was not considered in its design, all attempts to make
> it accessible have been fought by WhatWG members.

All attempts to expand its official, and reasonable accessible, use
as a dynamic variant of <img>, have been resisted.

You rightly criticize the original designers of canvas for not
considering accessibility in the initial design. It's very important
when designing features to consider all aspects of software quality such
as accessibility, performance, internationalization, security, usability
etc. A lot of the pushback against the expansion of canvas's text
editing capabilities is because the proposed extensions neglect some of
these aspects of software quality. It is unfortunate that aspects like
privacy are given short shrift in the early design of these features,
because it only leads to friction later in the process as we can see.

> Canvas is the closest thing to what developers are familiar with on
> Windows which today is the pervasive client platform.

Do Windows developers really tend to build UIs using a direct draw API?
Sounds … inefficient.

> If canvas is in the specification it will be used extensively and this
> leaves HTML itself inaccessible.

It was, is, and will be used extensively regardless of whether it is
or is not in the W3C specification.

Not being in HTML4 didn't prevent widespread use of <embed>.

Indeed, you yourself admit the specification has little power when you
say developers will abuse canvas no matter what the specification says
about it.

Anyhow, I think updating the accessibility tree with bounding boxes for
magnifiers and surfacing the caret blink rate are additions that are
necessary, as the Change Proposal states, even in the absence of text
editing, so this text editing debate is a bit of a red herring for this
issue.

--
Benjamin Hawkes-Lewis

Received on Friday, 29 April 2011 16:06:16 UTC