- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 19 Feb 2014 08:01:47 -0800
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.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: <CAGN7qDAzOi-Av+HxR5Yms6JPAEkJ0X+N+LmSFfRdK3hpBVAY4g@mail.gmail.com>
On Wed, Feb 19, 2014 at 1:53 AM, Steve Faulkner <faulkner.steve@gmail.com>wrote:
> hi Rik,
>
> so where does that leave the situation?
>
> 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.
I don't have an opinion but the minimal implementation in Mozilla currently
has no restrictions either (but we need to check what their opinion is)
> On 18 February 2014 17:30, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> 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>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Attachments
- image/gif attachment: graycol.gif
Received on Wednesday, 19 February 2014 16:02:20 UTC