Re: questions arising from AT vendor in regards to Mozillas implementation of the canvas subdom

This is the line of thinking that misses the point:
"The only thing I can come up with is to represent every single 
character or word in its own div and use css in weird and wonderful ways 
to make sure the location info ends up as required.".

The author of that brainstorming idea is well intentioned, but missing 
the point. We do not need pixel-for-pixel precision for text 
representation for ATs.
We do need to be able to do accurate caret browsing, we do need to be 
able to pass selections to the AT. And we do need high quality transforms.

Those are the issues, not character boundary maps. Nobody passes those 
to ATs. There is no AT that receives an integer array with the location 
of every character on the screen.
That said, authors can decide if they want to do something with that 
kind of information. That may be why they're using Canvas in the first 
place.

We have and continue to push for a method for authors to represent caret 
browsing. We're certainly keeping on eye on scroll and selection semantics.

There's this unfortunate tension, a repeated argument on the lists, that 
we should not be approaching these changes "piecemeal". Most of the web 
has been approached in a constructive fashion, gradually, through 
learning and re-implementation of desktop metaphors. This is no 
different, and some of it is much older than other web technologies. 
However, I do understand that we should have a thorough idea of what 
we're doing and trying to accomplish, instead of just taking on tasks in 
isolation. That's something I figured I could accomplish by implementing 
Canvas widgets. And it worked. That's how I got on-board with the 
handful of issues we've been discussing the past two years.

We are not doing this piecemeal; we have identified the majority of 
issues through real world testing and surveys.

We are doing this gradually, in large part, because many editors and 
vendor developers have pushed back against our use cases. That's 
unfortunate, but it will change. We've already seen it change with the 
PDF.js project, from a company that ejected their previous Bespin 
project. We've seen a change with Microsoft, from a company that 
wouldn't touch Canvas to one that is now committed to its accessibility.


-Charles


On 2/19/2012 5:20 PM, Richard Schwerdtfeger wrote:
>
> 1. subdom content should not be rendered at all. It has no visual 
> location.
> 2. We need the new API Frank has created to provide the location of 
> content in the subdom. If we need finer granularity on individual 
> characters we will deal with that when we can get consensus on rich 
> text editing. We don't have that at this point.
>
> I think we are jumping the gun trying to address the complex case 
> right now.
>
> Rich
>
> Rich
>
> Rich Schwerdtfeger
>
> Inactive hide details for Steve Faulkner ---02/17/2012 03:54:29 
> AM---Hi all, I would like to draw your attention to the followiSteve 
> Faulkner ---02/17/2012 03:54:29 AM---Hi all, I would like to draw your 
> attention to the following bug as it includes
>
> From: Steve Faulkner <faulkner.steve@gmail.com>
> To: public-canvas-api@w3.org,
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, ChCharles Pritchard 
> <chuck@jumis.com>, Frank Olivier <franko@microsoft.com>
> Date: 02/17/2012 03:54 AM
> Subject: questions arising from AT vendor in regards to Mozillas 
> implementation of the canvas subdom
>
> ------------------------------------------------------------------------
>
>
>
> Hi all,
> I would like to draw your attention to the following bug as it 
> includes questions about how the location of canvas subdom content is 
> to be conveyed to AT:
>
> Expose alternative content in Canvas element to ATs_
> __https://bugzilla.mozilla.org/show_bug.cgi?id=495912_
>
>
> any insights you may have would be benenficial
> -- 
> with regards
>
> Steve Faulkner
> Technical Director - TPG
> _
> _
>