Re: hit testing and retained graphics

hi ben,

It have seen it mentioned elsehwere that remote machine access is not an
appropaiate use of canvas.
I didn't ask about any particular user groups, but you chose to rephrase my
question.


Let me make it clear, i do not believe providing a duplicate shadow DOM
interface for remote OS/applications represented in the browser using canvas
as practical.

But i do think in this case and other cases, the provision of programmatic
focus on a defined area of the canvas is both practical and desirable.

For example if I increase the magnification in my browser to 200%, when an
element or object receives focus is offscreen, the view changes so it is no
longer offscreen. This does not happen if the objects are represented on the
canvas, regardless of whether they are local or remote.

regards
stevef



On 3 July 2011 10:56, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>wrote:

> On Sun, Jul 3, 2011 at 9:20 AM, Steve Faulkner <faulkner.steve@gmail.com>
> wrote:
> > I am assuming that no one disagrees that the use of canvas provide
> display
> > and interaction with a remote system is a legitimate use case?
>
> Do we want to allow people with disabilities to access remote systems
> through their web browser, when canvas is used for visual display? Sure.
>
> Like any use-case, this might or might not be one we can solve.
>
> Do we want to allow people with disabilities to access remote systems
> through their web browser with local AT, when canvas is used for
> visual display? Sure.
>
> But I'm pretty sure that *even* if we could provide features to enable
> this, nobody
> is going to step up to use those features, because the amount of work is
> huge
> and the benefits are slim.
>
> This is very different to the situation where people are building
> their own application
> that happens to use canvas for some custom controls or even a single canvas
> with widgets drawn directly onto the canvas.
>
> > If so, there is also the keyboard only case. the romote access app I
> linked
> > to works fine with the keyboard except that when focus moves offscreen
> the
> > view isn't modified  to display the focused content. I think this could
> be
> > fixed by the ability to define focusable areas on the the canvas. Again
> this
> > would not require access to the full remote accessibility stack.
>
> You're talking about a scenario where the canvas does not display the
> whole remote view? Wouldn't the best thing to do here be to zoom out
> the view until it fits the canvas? (Then remote zoom features could be
> used to follow cursor and keyboard focus around.)
>
> --
> Benjamin Hawkes-Lewis
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Sunday, 3 July 2011 12:17:35 UTC