Re: hit regions Firefox support update

On Tue, Feb 18, 2014 at 3:04 AM, Steve Faulkner <faulkner.steve@gmail.com>wrote:

> note: the issue of canvas sub dom restrictions is not new,  this was
> discussed back in mid 2012 and resulted in proposed changes the the canvas
> 2d context spec  to remove the restriction [1]
>
> an example of where the ability to use ARIA role, states and properties on
> divs and spans etc is this canvas rich UI library http://www.zebkit.com/
>
> [1]
> http://www.w3.org/html/wg/wiki/index.php?title=User:Eoconnor/ISSUE-201&oldid=13386#Details
>

You're correct! I forgot that the HTML WG had a change proposal on this.
The WG decided to remove the limitation [1] and I integrated this on Sep
22, 2012 [2]

So, at least for the w3c version of the spec, this has been fixed.

1: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-201#Details
2:
https://github.com/w3c/html/commit/450357fe6734bdd23efc9a9367b50438bafa3763


> On 17 February 2014 22:56, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:
>
>>  response between <rss> and </rss>
>>
>>
>> Rich Schwerdtfeger
>>
>> [image: Inactive hide details for Rik Cabanier ---02/17/2014 01:12:43
>> PM---On Mon, Feb 17, 2014 at 10:49 AM, Richard Schwerdtfeger <sch]Rik
>> Cabanier ---02/17/2014 01:12:43 PM---On Mon, Feb 17, 2014 at 10:49 AM,
>> Richard Schwerdtfeger <schwer@us.ibm.com>wrote:
>>
>>
>> From: Rik Cabanier <cabanier@gmail.com>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: Dominic Mazzoni <dmazzoni@google.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/17/2014 01:12 PM
>>
>> Subject: Re: hit regions Firefox support update
>> ------------------------------
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 17, 2014 at 10:49 AM, Richard Schwerdtfeger <
>> *schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>>
>>    Hi Rik,
>>
>>    Sure I can elaborate.
>>
>>    When I author ARIA markup I am going to set the role on the element
>>    in fallback content along with any ARIA states and properties I will have.
>>    The spec. says that I, as author, MUST us a control in fallback content
>>    (which I assume is an HTML5 control) or I am going to have to put a role in
>>    the API call that sets up the hit region. Why should I have to put a role
>>    in the API when I normally put it on an element in fallback content.
>>    Example:
>>
>>    <div role="checkbox" aria-checked="true">
>>
>>    vs. the spec. telling me I have to do:
>>
>>    <div aria-checked="true"> and supplying the role through the API.
>>    This makes no sense.
>>
>>
>> No, you don't have to do this. From the spec:
>>
>>    if any of the following conditions are met, throw a NotSupportedError
>>    exception and abort these steps.
>>       ...
>>       The arguments object's control and role members are both non-null.
>>
>> You are not allowed to specify a control and a role at the same time. The
>> role has to come from the control.
>>
>> You do have to provide a HTML control:
>>
>> <rss> What does it mean to apply a role but no corresponding element?
>> </rss>
>>
>>
>>    if any of the following conditions are met, throw a NotSupportedError
>>    exception and abort these steps.
>>       ...
>>       The arguments object's control member is not null but is neither
>>       an a element that represents a hyperlink, a button element, an input
>>       element whosetype attribute is in one of the Checkbox or Radio Button
>>       states, nor an input element that is a button.
>>
>>
>> Maybe that can be relaxed? (Why not text input for instance?)
>>
>> <rss> I think this needs to be relaxed a fair bit. Most web authors use
>> <div>s and <span>s in stead of standard input controls. Making it
>> accessible would require an ARIA role on the content as well as ARIA
>> attributes </rss>
>>
>>
>>    We also may have a situation like the following:
>>
>>    <table role="grid" onclick="foo()">
>>    <TR><TD>cell 1</td></tr>
>>    </table>
>>
>>    The hit test region could be for cell 1 and then bubble up to the
>>    grid.
>>
>>
>> That is allowed. The event is routed to cell 1 and will then bubble
>> <rss> My point being the TD is not a standard input control. So, if it is
>> not an input control then the spec. wants you to supply a role but authors
>> do more than supply roles. Let's talk about this on the call. Perhaps Ian
>> will participate on the call today. </rss>
>>
>>
>>
>>    [image: Inactive hide details for Rik Cabanier ---02/17/2014 12:35:13
>>    PM---On Mon, Feb 17, 2014 at 9:16 AM, Richard Schwerdtfeger <schw]Rik
>>    Cabanier ---02/17/2014 12:35:13 PM---On Mon, Feb 17, 2014 at 9:16 AM,
>>    Richard Schwerdtfeger <*schwer@us.ibm.com* <schwer@us.ibm.com>>wrote:
>>    > Rik,
>>
>>
>>
>>    From: Rik Cabanier <*cabanier@gmail.com* <cabanier@gmail.com>>
>>    To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>>    Cc: Dominic Mazzoni <*dmazzoni@google.com* <dmazzoni@google.com>>,
>>    Jay Munro <*jaymunro@microsoft.com* <jaymunro@microsoft.com>>, Mark
>>    Sadecki <*mark@w3.org* <mark@w3.org>>, "*public-canvas-api@w3.org*<public-canvas-api@w3.org>"
>>    <*public-canvas-api@w3.org* <public-canvas-api@w3.org>>, Alexander
>>    Surkov <*surkov.alexander@gmail.com* <surkov.alexander@gmail.com>>
>>    Date: 02/17/2014 12:35 PM
>>
>>    Subject: Re: hit regions Firefox support update
>>    ------------------------------
>>
>>
>>
>>
>>
>>
>>    On Mon, Feb 17, 2014 at 9:16 AM, Richard Schwerdtfeger <
>>    *schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>>       Rik,
>>
>>       That design is fundamentally broken for these reasons:
>>
>>    If you were OK with the focus ring API, why are you not OK with hit
>>    regions? It seems hit regions can do everything that focus rings could do
>>    (except of course draw the focus boundary which is why we still have that
>>    API)
>>       1. It is frankly stupid that the fallback element needs to be an
>>       HTML5 control and not having their be a role in fallback content because
>>       authors are going to have to add states and properties.
>>
>>    Is the issue that there's no requirement for a role?
>>    Can you elaborate?
>>
>>       2. Why would we make the author have to implement half the ARIA
>>       work in the Canvas API and the other half in the fallback content?
>>
>>    Is this because you need to tag a group of elements with a role and
>>    you can't assign a control to it?
>>    If so, that is indeed a bit strange, but I don't really see a way
>>    around it. Hit regions ignore the structure of the canvas shadow DOM so you
>>    have to recreate it.
>>
>>       3. Events Bubble and a container may handle the event.
>>
>>       In short making these restrictive requirements makes absolutely no
>>       technical sense whatsoever. It makes things harder on the developer.
>>
>>    What would you like to see?
>>
>>
>>       [image: Inactive hide details for Rik Cabanier ---02/17/2014
>>       10:00:08 AM---On Mon, Feb 17, 2014 at 6:31 AM, Richard Schwerdtfeger <schw]Rik
>>       Cabanier ---02/17/2014 10:00:08 AM---On Mon, Feb 17, 2014 at 6:31 AM,
>>       Richard Schwerdtfeger <*schwer@us.ibm.com* <schwer@us.ibm.com>>wrote:
>>       > Rik,
>>
>>
>>
>>       From: Rik Cabanier <*cabanier@gmail.com* <cabanier@gmail.com>>
>>       To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>>       Cc: Dominic Mazzoni <*dmazzoni@google.com* <dmazzoni@google.com>>,
>>       Jay Munro <*jaymunro@microsoft.com* <jaymunro@microsoft.com>>,
>>       Mark Sadecki <*mark@w3.org* <mark@w3.org>>, "
>>       *public-canvas-api@w3.org* <public-canvas-api@w3.org>" <
>>       *public-canvas-api@w3.org* <public-canvas-api@w3.org>>, Alexander
>>       Surkov <*surkov.alexander@gmail.com* <surkov.alexander@gmail.com>>
>>       Date: 02/17/2014 10:00 AM
>>
>>       Subject: Re: hit regions Firefox support update
>>
>>       ------------------------------
>>
>>
>>
>>
>>
>>
>>       On Mon, Feb 17, 2014 at 6:31 AM, Richard Schwerdtfeger <
>>       *schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>>          Rik,
>>
>>          Inherit, at this time, must mean that the role passed to
>>          correspond with the fallback element must be available as an element
>>          attribute on that element otherwise an accessibility test tool will not
>>          pick it up.
>>
>>       What is the "role passed to correspond with the fallback element"?
>>       You either have a control or you pass a role. It's not allowed to
>>       do both
>>
>>          Another issue is that if there were a role on the fallback
>>          element we cannot simply replace it as the ATs will not pick up role
>>          changes. You would actually have to delete the node and create a new one in
>>          its place having a new role.
>>
>>          Rich
>>
>>
>>          Rich Schwerdtfeger
>>
>>          [image: Inactive hide details for Rik Cabanier ---02/16/2014
>>          12:08:18 PM---On Sun, Feb 16, 2014 at 8:50 AM, Richard Schwerdtfeger <schw]Rik
>>          Cabanier ---02/16/2014 12:08:18 PM---On Sun, Feb 16, 2014 at 8:50 AM,
>>          Richard Schwerdtfeger <*schwer@us.ibm.com* <schwer@us.ibm.com>>wrote:
>>          > Congrats to Mozil
>>
>>          From: Rik Cabanier <*cabanier@gmail.com* <cabanier@gmail.com>>
>>          To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>>          Cc: Dominic Mazzoni <*dmazzoni@google.com* <dmazzoni@google.com>>,
>>          Alexander Surkov <*surkov.alexander@gmail.com*<surkov.alexander@gmail.com>>,
>>          "*public-canvas-api@w3.org* <public-canvas-api@w3.org>" <
>>          *public-canvas-api@w3.org* <public-canvas-api@w3.org>>, Mark
>>          Sadecki <*mark@w3.org* <mark@w3.org>>, Jay Munro <
>>          *jaymunro@microsoft.com* <jaymunro@microsoft.com>>
>>          Date: 02/16/2014 12:08 PM
>>
>>
>>          Subject: Re: hit regions Firefox support update
>>
>>          ------------------------------
>>
>>
>>
>>
>>
>>
>>          On Sun, Feb 16, 2014 at 8:50 AM, Richard Schwerdtfeger <
>>          *schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>>             Congrats to Mozilla! We will still need the
>>             drawFocusIfNeeded though per Rik's comment below.
>>
>>             One concern I have about the current hit region spec. is
>>             that it only allows the author to provide a role that does not show up in
>>             the DOM so until we get some changes in that we want for ARIA 1.1 (to query
>>             the role) the accessibility test tools won't pick up the role.
>>             Additionally, a role is not enough. We need states and properties. We would
>>             be better to simply apply ARIA attributes to the DOM at this time.
>>
>>          Hi Rich,
>>
>>          the minimal implementation always requires that you provide a
>>          control (= an element in the fallback content).
>>          The region is supposed to inherit the ARIA role of that
>>          element. Would that not be sufficient?
>>
>>
>>             [image: Inactive hide details for Dominic Mazzoni
>>             ---02/14/2014 01:36:50 PM---I'm interested in implementing hit regions in
>>             Chrome, but]Dominic Mazzoni ---02/14/2014 01:36:50 PM---I'm
>>             interested in implementing hit regions in Chrome, but I haven't discussed
>>             it with all of the sta
>>
>>             From: Dominic Mazzoni <*dmazzoni@google.com*<dmazzoni@google.com>
>>             >
>>             To: Jay Munro <*jaymunro@microsoft.com*<jaymunro@microsoft.com>
>>             >
>>             Cc: Rik Cabanier <*cabanier@gmail.com* <cabanier@gmail.com>>,
>>             Alexander Surkov <*surkov.alexander@gmail.com*<surkov.alexander@gmail.com>>,
>>             "*public-canvas-api@w3.org* <public-canvas-api@w3.org>" <
>>             *public-canvas-api@w3.org* <public-canvas-api@w3.org>>, Mark
>>             Sadecki <*mark@w3.org* <mark@w3.org>>
>>             Date: 02/14/2014 01:36 PM
>>
>>
>>             Subject: Re: hit regions Firefox support update
>>
>>             ------------------------------
>>
>>
>>
>>
>>             I'm interested in implementing hit regions in Chrome, but I
>>             haven't discussed it with all of the stakeholders at Google yet. I'm really
>>             excited to see that Mozilla has already implemented it and that should
>>             definitely give us some momentum.
>>
>>             On Fri, Feb 14, 2014 at 11:25 AM, Jay Munro <
>>             *jaymunro@microsoft.com* <jaymunro@microsoft.com>> wrote:
>>                Lets see what folks say Monday on hit regions, whether we
>>                put them in CR or not. Mark, want to add it to the agenda?
>>
>>
>>                Sent from my Windows Phone
>>                ------------------------------
>>                *From: *Rik Cabanier
>> * Sent: *2/14/2014 11:20 AM
>>
>> * To: *Jay Munro
>> * Cc: *Alexander Surkov; *public-canvas-api@w3.org*<public-canvas-api@w3.org>;
>>                Mark Sadecki
>> * Subject: *Re: hit regions Firefox support update
>>
>>
>>
>>
>>                On Fri, Feb 14, 2014 at 10:41 AM, Jay Munro <
>>                *jaymunro@microsoft.com* <jaymunro@microsoft.com>> wrote:
>>                   We've already removed all the at risk features with
>>                   the exception of drawFocusIfNeeded , which was agreed
>>                   upon in the A11y subgroup.
>>
>>
>>                We'll have to bring it back if we want a11y to work in
>>                canvas :-(
>>
>>                   *From:* Rik Cabanier [mailto:*cabanier@gmail.com*<cabanier@gmail.com>]
>>
>> * Sent:* Friday, February 14, 2014 10:15 AM
>> * To:* Jay Munro
>> * Cc:* Alexander Surkov; *public-canvas-api@w3.org*<public-canvas-api@w3.org>;
>>                   Mark Sadecki
>>
>>
>> * Subject:* Re: hit regions Firefox support update
>>
>>
>>
>>
>>
>>
>>
>>                   On Fri, Feb 14, 2014 at 9:40 AM, Jay Munro <
>>                   *jaymunro@microsoft.com* <jaymunro@microsoft.com>>
>>                   wrote:
>>
>>                   Do we have a 2nd implementation of hitRegions?
>>
>>
>>
>>                   We do not.
>>
>>                   They are listed as at-risk so we can still go to CR
>>                   with them.
>>
>>
>>
>>                   We should probably update the at-risk list to state
>>                   that *part* or all of hit regions might be removed.
>>
>>
>>
>>
>>
>>
>>
>> * From:* Rik Cabanier [mailto:*cabanier@gmail.com* <cabanier@gmail.com>]
>> * Sent:* Friday, February 14, 2014 9:33 AM
>> * To:* Alexander Surkov
>> * Cc:* *public-canvas-api@w3.org* <public-canvas-api@w3.org>; Mark
>>                      Sadecki
>> * Subject:* Re: hit regions Firefox support update
>>
>>
>>
>>                      I just requested that the patches are checked into
>>                      firefox.
>>
>>                      If all goes well, this means that the upcoming
>>                      nightly build will have basic support for hit regions.
>>
>>
>>
>>                      If people had earlier tests for drawFocusIfNeeded,
>>                      they can simply update them as follows.
>>
>>                      old code:
>>
>>
>>
>>
>>                         ctx.drawFocusIfNeeded(element);
>>
>>                      new code:
>>                         ctx.drawFocusIfNeeded(element);
>>                         ctx.addHitRegion({control: element};
>>
>>
>>
>>
>>
>>
>>
>>                      Alex, how can we turns hit regions and focus rings
>>                      on by default?
>>
>>
>>
>>                      On Thu, Feb 13, 2014 at 10:40 AM, Alexander Surkov <
>>                      *surkov.alexander@gmail.com*<surkov.alexander@gmail.com>>
>>                      wrote:
>>
>>                      Hi. Here's an update of hit region implementation
>>                      in Firefox in case if you're curious .
>>
>>                      This week we've got a prototype of hit regions
>>                      which can be used to change accessible boundaries. The work hasn't been
>>                      landed into Firefox Nightly yet but there's a try build [2].
>>
>>                      There's no plans to continue the work on
>>                      drawFocusIfNeeded to fit it for accessible boundaries setting since hit
>>                      regions looks promising. It's worth to notice though that drawFocusIfNeeded
>>                      (used to draw the focus) is part of Firefox and there's no actions to undo
>>                      this.
>>
>>
>>
>>                      You can follow hit regions work by watching Mozilla
>>                      bug [1].
>>
>>                      Thanks.
>>                      Alexander.
>>
>>
>>                      [1]
>>                      *https://bugzilla.mozilla.org/show_bug.cgi?id=966591*<https://bugzilla.mozilla.org/show_bug.cgi?id=966591>
>>                      [2]
>>                      *https://tbpl.mozilla.org/?tree=Try&rev=a0775f0bf042*<https://tbpl.mozilla.org/?tree=Try&rev=a0775f0bf042>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Received on Tuesday, 18 February 2014 17:30:33 UTC