Re: hit regions Firefox support update

It should be any any fallback element for the canvas element it pertains
to. As you I am sure are aware hit testing came from mouse hit testing on
the desktop. The desktop is nothing more than a bitmap (like canvas) at the
end of the day and the DOM basically aligns with the object tree on the
desktop.

It should be the authors job to ensure that fallback content, as a minumum,
supports the important UI objects drawn the canvas for accessibility.
Ideally we would like to dispatch pointer events to the same elements we
have keyboard handlers on in fallback content but it should not be a
limitation. That would be an accessible authoring discussion.

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Rik Cabanier <cabanier@gmail.com>, Steve Faulkner
            <faulkner.steve@gmail.com>, Jay Munro <jaymunro@microsoft.com>,
            Mark Sadecki <mark@w3.org>, "public-canvas-api@w3.org"
            <public-canvas-api@w3.org>, Alexander Surkov
            <surkov.alexander@gmail.com>
Date:	02/19/2014 03:05 PM
Subject:	Re: hit regions Firefox support update



OK. I'll bring the whatwg discussion to a close. Is Mozilla in agreement to
not restrict which elements can be the target of a hit region? Or should it
be any focusable element? What about a non-focusable element that can still
get click events that a magnifier might still want to know the bounds of?


On Wed, Feb 19, 2014 at 11:23 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  All:

  We need the less restrictive version of the API. There will be times
  where we have controls whereby you need access to subcomponents to tie
  the region location to - such as a combo box. An HTML5 select will not
  allow you to provide this level of control. Furthermore all HTML5
  elements support tabindex. The restrictions would largely require us to
  restrict keyboard navigation to form controls in fallback content which
  would take the web back to 2004 when we started WAI-ARIA. If there is an
  opportunity to use HTML5 standard controls in fallback then by all means
  we should use them but the restriction only holds us back - not unlike
  authors who chose to use custom UI controls with script and css. Canvas
  is all about creating a custom UI.

  I am not able to post to WhatWG but we must remove the restrictions if
  this is to work properly.

  Rich


  Rich Schwerdtfeger




  Inactive hide details for Dominic Mazzoni ---02/19/2014 01:04:33 PM---On
  Wed, Feb 19, 2014 at 8:01 AM, Rik Cabanier <cabanier@gDominic Mazzoni
  ---02/19/2014 01:04:33 PM---On Wed, Feb 19, 2014 at 8:01 AM, Rik Cabanier
  <cabanier@gmail.com> wrote: >

  From: Dominic Mazzoni <dmazzoni@google.com>
  To: Rik Cabanier <cabanier@gmail.com>
  Cc: Steve Faulkner <faulkner.steve@gmail.com>, Richard
  Schwerdtfeger/Austin/IBM@IBMUS, Jay Munro <jaymunro@microsoft.com>, Mark
  Sadecki <mark@w3.org>, "public-canvas-api@w3.org" <
  public-canvas-api@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
  Date: 02/19/2014 01:04 PM

  Subject: Re: hit regions Firefox support update



  On Wed, Feb 19, 2014 at 8:01 AM, Rik Cabanier <cabanier@gmail.com> wrote:
              do we have implementer agreement on the less restrictive
              definition in canvas 2d context spec or do we have convince
              hixie over on whatwg?

        I think we do.
        Dominic is arguing for less restrictions on WhatWG and the original
        change request was authored by Ted O'Connor from Apple.

  Steve, do you want to chime in too? I feel like we're just going in
  circles.