- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 18 Feb 2014 11:04:56 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, 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: <CA+ri+Vm5G3oMBwoPcQrKzSpZky6Fjp0YD_yR7d4aYZdctd-gkA@mail.gmail.com>
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
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
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>
>
>
>
>
>
>
>
>
>
>
Attachments
- image/gif attachment: graycol.gif
Received on Tuesday, 18 February 2014 11:06:07 UTC