W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: hit testing and retained graphics

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Sun, 3 Jul 2011 13:16:46 +0100
Message-ID: <CA+ri+Vnd_iZUBFuvk0KyWsAz=c-KGFS+BWOv+4utw_KyFhxsLQ@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Charles Pritchard <chuck@jumis.com>, Henri Sivonen <hsivonen@iki.fi>, Sean Hayes <Sean.Hayes@microsoft.com>, "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Charles McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
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

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.


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 |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 3 July 2011 12:17:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:31 UTC