W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2010

Re: html5 editor responds to Canvas accessibility related bugs

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 8 Oct 2010 03:14:11 +0000 (UTC)
To: Charles Pritchard <chuck@jumis.com>
cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Message-ID: <Pine.LNX.4.64.1010080218340.8618@ps20323.dreamhostps.com>
On Thu, 7 Oct 2010, Charles Pritchard wrote:
> On 10/6/2010 12:16 AM, Benjamin Hawkes-Lewis wrote:
> >
> >     * Wordle : http://benjamin.smedbergs.us/wordmap/wordmap.html
> >     * Mind map : http://think-app.appspot.com/
> >     * Names and dates in a genealogical tree : http://bencrowder.net/blog/2009/10/pedigree-chart-using-html5/
> >     * Labels in diagrams : http://diagramo.com/
> > 
> > These probably do involve text editing, but one could easily imagine 
> > non-editable versions, which would still benefit from caret navigation 
> > and selection.
> 
> Ian, are any of these sufficient, do we need more use cases?

In what sense are these use cases? I tried to poke around at each one, but 
none of them seemed to do anything that would require caret or selection 
APIs. In fact, none of them seemed to even do the most basic things to 
make their canvases accessible. Only two of them allow the user to 
interact with the text, as far as I can see; in both cases, the text 
editing is fully accessible as is and requires no new API to be made 
accessible. If anything, I'd say these are an indication that authors are 
satisfied enough with the editing features that already exist in HTML 
that they don't feel the need to reimplement them manually.

I would also add that given that the <canvas> parts of these pages are 
completely inaccessible currently, not even using the most basic features 
we've provided to make such pages accessible, it is rather premature to 
consider what we could do to help them make their pages accessible if they 
were to decide to switch from using the existing simple text editing 
features to building their own from scratch.

In any case, as I've said before: if someone can come up with a way to 
make an API for these features that addresses the needs I listed (which, 
based on past experience with accessibility APIs, would likely be the 
minimum necessary to actually improve accessibility on the Web for pages 
whose authors write their own editors), and assuming that browsers would 
be willing to support them, then there's no question that we'd add them to 
the spec. I just don't think that working on such an API is the most 
time-efficient way of improving the Web platform's accessibility story. We 
could improve life for users of ATs faster by working on other things.

There is an opportunity cost to working on any one feature. If feature A 
improves the life of one million AT users and takes one man-month, and 
feature B improves the life of two million AT users and takes one 
man-month, then a world in which we work on feature A before feature B has 
more disenfranchised users than a world in which we work on feature B 
before feature A.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 8 October 2010 03:14:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 October 2010 03:14:40 GMT