- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 17 Feb 2014 11:11:58 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- 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>
- Message-ID: <CAGN7qDAfGfT-veaaCS-oFwP41znwqEMFq7KLztB-XHu9Q5BMzA@mail.gmail.com>
On Mon, Feb 17, 2014 at 10:49 AM, Richard Schwerdtfeger
<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:
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?)
> 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
>
>
> [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>wrote: > Rik,
>
>
> 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 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>
>
>
>
>
>
>
>
>
>
>
Attachments
- image/gif attachment: graycol.gif
Received on Monday, 17 February 2014 19:12:29 UTC