W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: feedback requested: Canvas change for improved hit testing that also facilitates accessibility

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






graycol.gif
(image/gif attachment: graycol.gif)

Received on Tuesday, 5 April 2011 15:59:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:27 GMT