- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Mon, 17 Feb 2014 12:49:06 -0600
- To: Rik Cabanier <cabanier@gmail.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: <OFBBD3829D.A9650CE6-ON86257C82.00666E22-86257C82.00675F0F@us.ibm.com>
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.
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.
Rich
Rich Schwerdtfeger
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>
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?
Inactive hide details for Rik Cabanier ---02/17/2014 10:00:08 AM---On
Mon, Feb 17, 2014 at 6:31 AM, Richard Schwerdtfeger <schwRik Cabanier
---02/17/2014 10:00:08 AM---On Mon, Feb 17, 2014 at 6:31 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 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
> 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
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>wrote: > Congrats
to Mozil
From: Rik Cabanier <cabanier@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Dominic Mazzoni <dmazzoni@google.com>, Alexander Surkov <
surkov.alexander@gmail.com>, "public-canvas-api@w3.org" <
public-canvas-api@w3.org>, Mark Sadecki <mark@w3.org>, Jay Munro <
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> 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?
Inactive hide details for Dominic Mazzoni ---02/14/2014
01:36:50 PM---I'm interested in implementing hit regions in
Chrome, butDominic 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>
To: Jay Munro <jaymunro@microsoft.com>
Cc: Rik Cabanier <cabanier@gmail.com>, Alexander Surkov <
surkov.alexander@gmail.com>, "public-canvas-api@w3.org" <
public-canvas-api@w3.org>, Mark Sadecki <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> 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; Mark
Sadecki
Subject: Re: hit regions Firefox support update
On Fri, Feb 14, 2014 at 10:41 AM, Jay Munro <
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]
Sent: Friday, February 14, 2014 10:15 AM
To: Jay Munro
Cc: Alexander Surkov; 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> 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]
Sent: Friday, February 14, 2014 9:33 AM
To: Alexander Surkov
Cc: 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> 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
[2]
https://tbpl.mozilla.org/?tree=Try&rev=a0775f0bf042
Attachments
- image/gif attachment: graycol.gif
Received on Monday, 17 February 2014 18:49:38 UTC