- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Wed, 19 Feb 2014 09:53:48 +0000
- To: Rik Cabanier <cabanier@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: <CA+ri+V=g-FmPW5VjWTRGK0Cpg=D57x9dnQ+ps7AcwNjVq9XO3Q@mail.gmail.com>
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?
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
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 09:55:03 UTC