- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 5 Apr 2011 10:56:10 -0500
- To: Oliver Hunt <oliver@apple.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com, cyns@exchange.microsoft.com, david.bolter@gmail.com, faulkner.steve@gmail.com, franko@microsoft.com, public-canvas-api@w3.org, public-canvas-api-request@w3.org, public-html@w3.org, public-html-a11y@w3.org, public-html-request@w3.org
- Message-ID: <OFD126773D.F79C391C-ON86257869.005535B3-86257869.005789E9@us.ibm.com>
Oliver,
GDI provides the data needed for hit testing. What API are you looking for?
GDI with hit testing?
http://www.syncfusion.com/faq/windowsforms/faq_c74c.aspx
Getting back to the retained graphics discussion. In their own way
assistive technologies like magnifiers or screen readers have their own
version of a retained model of what is on the screen. They need to know:
- What are the perceivable objects?
- Where are they so I can go to them (magnifier)?
- What is the font information?
- What is the role, state, and property information?
This is why it is important to associate ALL this information with
perceivable objects on the screen.
So, what happens (I am breaking out the cobwebs).
a device context is created.
The device context has associated: font, foreground and background color,
brush, clipping region, bounding rectangle, etc.
the device context is associated with a window handle (a window handle may
have multiple device contexts associated with drawing objects within that
area.
The OS calls into each window handle with a mouse event, like a click, and
you determine if the point is within the rectangle.
Here is an example for text:
http://msdn.microsoft.com/en-us/library/dd756613
(v=vs.85).aspx#step_1:_create_a_text_layout.
What is very important is that the bounding rectangle information needed
for hit testing is garnered from the GDI device context data structure. So,
tieing this back to canvas, we would need to:
- bind a draw path encompassing each visual object on canvas to a fallback
element in the canvas subtree. At assignment time a best fit bounding
rectangle is assigned to the bounding rectangle in the accessible object
created by the user agent for that fallback element
- Have canvas manage a hierarchy of last drawn objects to manage the hit
test. That which is last drawn is on top in the canvas. So, if there if one
object's bounding path overlaps another it is the last one drawn on top
that receives the pointing event.
- When it is determined that the hit (say an onclick) is within a drawpath
of an object pass the event to the element in the canvas subtree. This same
element should be also be capable of receiving keyboard events for that
object. Note: in Windows you might have bound these to COM.
Hope this helps.
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
From: Oliver Hunt <oliver@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com,
cyns@exchange.microsoft.com, david.bolter@gmail.com,
faulkner.steve@gmail.com, franko@microsoft.com,
public-canvas-api@w3.org, public-canvas-api-request@w3.org,
public-html@w3.org, public-html-a11y@w3.org,
public-html-request@w3.org
Date: 03/30/2011 04:19 PM
Subject: Re: feedback requested: Canvas change for improved hit testing
that also facilitates accessibility
The first result i find for hit testing in GDI is
http://msdn.microsoft.com/en-us/library/ms969920.aspx
Which implies to me that they expect a developer to do their own hit
testing.
I am surprised that GDI provides any automatic hit testing for drawing to
an HDC, but before commenting further I need to see an example of the API,
can you point me at documentation or code that uses it?
--Oliver
On Mar 30, 2011, at 1:51 PM, Richard Schwerdtfeger wrote:
Oliver,
GDI provides and infrastructure that supports hit testing in Windows.
The bounding rectangle of each device context is bound to the object
and used in hit testing along with Z-order, etc. What I am telling
you is that many developers are using canvas beyond the limitations
and not going to SVG because for people working in the Windows space
Canvas is closer to what they know. I am also saying that we need a
vehicle for supplying the bounds of a UI object for accessibility.
This has, on Windows, been tied to this device context bounding
rectangle.
From an accessibility perspective telling a developer they should not
do something in canvas easily so go use SVG does not work.
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
<graycol.gif>Oliver Hunt ---03/30/2011 02:20:27 PM---On Mar 30, 2011,
at 12:06 PM, Richard Schwerdtfeger wrote: > Oliver,
From: Oliver Hunt <oliver@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com,
cyns@exchange.microsoft.com, david.bolter@gmail.com,
faulkner.steve@gmail.com, franko@microsoft.com,
public-canvas-api@w3.org, public-canvas-api-request@w3.org,
public-html@w3.org, public-html-a11y@w3.org,
public-html-request@w3.org
Date: 03/30/2011 02:20 PM
Subject: Re: feedback requested: Canvas change for improved hit
testing that also facilitates accessibility
On Mar 30, 2011, at 12:06 PM, Richard Schwerdtfeger wrote:
Oliver,
It is an attempt to simplify hit testing in canvas while at the
same time providing a vehicle to tell an assistive technology
the bounds of the corresponding UI object being drawn on canvas
as represented in fallback content. Currently there is no
mapping. These bounds are needed by screen magnifiers for
zooming and screen readers for Braille support (earlier post).
Now the canvas author has to manage all the hit testing. This
is a canvas deficiency that should have been in place to start
- so grafting seems like an inappropriate response.
Consequently, I am also seeing canvas applications that create
the equivalent of visio by creating separate canvas elements
overlayed on top of another canvas to represent drawing
objects. This is very inefficient and will get worse unless
something is done.
This is not a canvas deficiency -- canvas is an immediate mode
renderer, one of the things you have to handle yourself when dealing
with _any_ immediate mode renderer is hit detection. This is true of
Canvas, GDI, CG, raw component painting in Java, etc, etc
If you want hit detection to be done for you, you want a retained
mode renderer, such as SVG.
--Oliver
Rich Schwerdtfeger
CTO Accessibility Software Group
<graycol.gif>Oliver Hunt ---03/30/2011 12:11:53 PM---This feels
like an attempt to graft retained mode rendering on to canvas,
what am i missing? --Olive
From: Oliver Hunt <oliver@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com,
cyns@exchange.microsoft.com, david.bolter@gmail.com,
faulkner.steve@gmail.com, franko@microsoft.com,
public-canvas-api@w3.org, public-html@w3.org,
public-html-a11y@w3.org, public-html-request@w3.org
Date: 03/30/2011 12:11 PM
Subject: Re: feedback requested: Canvas change for improved hit
testing that also facilitates accessibility
Sent by: public-canvas-api-request@w3.org
This feels like an attempt to graft retained mode rendering on
to canvas, what am i missing?
--Oliver
On Mar 30, 2011, at 8:39 AM, Richard Schwerdtfeger wrote:
Thanks Boris. Sorry for being a pest but I really want
developers to work through the issues.
So, you would do the following:
- Assign the a closed draw path to an element in fallback
content: setClickableRegion(element). This immediately
makes the association and places it at the bottom of the
list.
- Any time you draw the element it moves it to the top of
the list.
- If the fallback element is removed the association
would need to go away. I did not address that so I will
need to add that to the proposal
- When a pointer event (click, etc.) goes to the fallback
element the normal capture/bubbling event processing
would apply
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
<graycol.gif>Boris Zbarsky ---03/30/2011 10:05:48 AM---On
3/30/11 10:55 AM, Richard Schwerdtfeger wrote: > Seeing
as nobody has commented can we assume tha
From: Boris Zbarsky <bzbarsky@mit.edu>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-canvas-api@w3.org, public-html@w3.org,
public-html-a11y@w3.org, public-html-request@w3.org,
chuck@jumis.com, cyns@exchange.microsoft.com,
david.bolter@gmail.com, faulkner.steve@gmail.com,
franko@microsoft.com
Date: 03/30/2011 10:05 AM
Subject: Re: feedback requested: Canvas change for
improved hit testing that also facilitates accessibility
On 3/30/11 10:55 AM, Richard Schwerdtfeger wrote:
> Seeing as nobody has commented can we assume that
developers have no
> problem with our totally changing the canvas 2D API to
support clickable
> regions?
It might just mean that people don't read their mailing
list spam every
few hours.
>From reading over your proposal, I'm not sure I follow
how it would
behave in the face of DOM mutations (e.g. elements being
removed from
the fallback content).
Or put another way, once you draw, you're permanently
attaching some
element to the canvas, right? Or is that not the
proposal?
-Boris
Attachments
- image/gif attachment: graycol.gif
Received on Tuesday, 5 April 2011 15:59:05 UTC