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

Re: html5 editor responds to Canvas accessibility related bugs

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Fri, 8 Oct 2010 07:44:35 +0100
Cc: Charles Pritchard <chuck@jumis.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Message-Id: <1C45F4E5-265E-49FF-B275-0E8876A6D6AC@googlemail.com>
To: Ian Hickson <ian@hixie.ch>
On 8 Oct 2010, at 04:14, Ian Hickson wrote:

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

Just to be clear, my point is that presented with (say) a dynamically drawn genealogical tree, a user might want to caret navigate to a name, select the name's text, and copy it for use elsewhere. This doesn't necessarily involve any changing (editing) of text.

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

Does anyone have any specific API proposals to put on the table to resolve Bugs 10248 and 10249?

Benjamin Hawkes-Lewis
Received on Friday, 8 October 2010 06:45:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:51 UTC