958241 - Update drawCustomFocusRing so it notifies the a11y code of the correct bounding rect

Status: RESOLVED WONTFIX

(Core :: Graphics: Canvas2D, defect)

Comment 1

[Rik Cabanier]

Attachment: Passed focus rectangle to model + integrated it in a11y DOM

Comment 2

[Rik Cabanier]

Attachment: Passed focus rectangle to model + integrated it in a11y DOM

Comment 3

[Rik Cabanier]

Comment on attachment 8361982 [details] [diff] [review]
Passed focus rectangle to model + integrated it in a11y DOM

try build: https://tbpl.mozilla.org/?tree=Try&rev=4e2d3235fefc

Comment 4

[Trevor Saunders (:tbsaunde)]

Comment on attachment 8361982 [details] [diff] [review]
Passed focus rectangle to model + integrated it in a11y DOM

I don't think is a good idea at all.  It means that the bounds of the one focused accessible will be out of sync with the bounds for all the other accessibles for the shadow dom / hit regions (if we implement that).  Besides this API just isn't set up for storing persistant state which is what all accessibility APIs use for bounds of focused things.

Comment 5

[Trevor Saunders (:tbsaunde)]

wontfix per comment 4 this API should just be for drawing focus rings. hit regions / shadow dom / standard focus should be what accessibility APIs use.

Comment 6

[Rik Cabanier]

During discussion on the canvas mailing list and the canvas a11y meetings, it is clear that this API sets the bounds in the a11y DOM.
This is how it's implemented in Chrome and how it will be implemented in IE.

The original patch that set the bounds was also accepted by FF. Roc just didn't like where the bounds were stored.

It's unfortunate that we have to go through this discussion again...

Comment 7

[alexander :surkov (:asurkov)]

Personally I didn't like this API and I did same points as Trevor did and it seems others more or less agreed on them. But we don't have anything better and I personally don't have time/passion to get into the approach deeper to invent something nicer. So my position is as long as Rik works and Mozilla makes mostly review-only job then I think we just let the approach in Firefox. After all this makes the web a bit more accessible.

Comment 8

[Rik Cabanier]

Comment on attachment 8361982 [details] [diff] [review]
Passed focus rectangle to model + integrated it in a11y DOM

yes, I will follow up with making canvas a11y compliant.

Comment 9

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #7)
> Personally I didn't like this API and I did same points as Trevor did and it
> seems others more or less agreed on them. But we don't have anything better

its not our job to invent APis for other people.  The API they want isn't acceptible, so they can suggest another one.

> and I personally don't have time/passion to get into the approach deeper to
> invent something nicer. So my position is as long as Rik works and Mozilla

hit regions look pretty reasonable imo.

> makes mostly review-only job then I think we just let the approach in
> Firefox. After all this makes the web a bit more accessible.

I don't think we should take every patch that makes one thing better and breaks other stuff.

(In reply to Rik Cabanier from comment #6)
> During discussion on the canvas mailing list and the canvas a11y meetings,

no, its pretty clear that's false read http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html again, please don't make me go digging through my irc logs for hixi saying the same thing while you were there...

> it is clear that this API sets the bounds in the a11y DOM.
> This is how it's implemented in Chrome and how it will be implemented in IE.

then I guess there violating the spec in addition to being insane...

> The original patch that set the bounds was also accepted by FF. Roc just
> didn't like where the bounds were stored.

maybe you should try implementing something reasonable, then people won't have reason to object.

Comment 10

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #9)
> (In reply to alexander :surkov from comment #7)
> > Personally I didn't like this API and I did same points as Trevor did and it
> > seems others more or less agreed on them. But we don't have anything better
> 
> its not our job to invent APis for other people.

Mozilla people are generally involved into API designing process. If there are objections then it's more productive to come with ideas rather than denial.

>  The API they want isn't
> acceptible, so they can suggest another one.

The API was accepted by Chrome and as Rik says IE team is going to implement it.

> > and I personally don't have time/passion to get into the approach deeper to
> > invent something nicer. So my position is as long as Rik works and Mozilla
> 
> hit regions look pretty reasonable imo.

I think I don't follow the idea, how is it connected with accessibility APIs? 

> > makes mostly review-only job then I think we just let the approach in
> > Firefox. After all this makes the web a bit more accessible.
> 
> I don't think we should take every patch that makes one thing better and
> breaks other stuff.

the method shouldn't really break any stuff if it's used properly.

> (In reply to Rik Cabanier from comment #6)
> > During discussion on the canvas mailing list and the canvas a11y meetings,
> 
> no, its pretty clear that's false read
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> element.html again, please don't make me go digging through my irc logs for
> hixi saying the same thing while you were there...
> 
> > it is clear that this API sets the bounds in the a11y DOM.
> > This is how it's implemented in Chrome and how it will be implemented in IE.
> 
> then I guess there violating the spec in addition to being insane...

what spec violation you talk about? reading http://www.w3.org/TR/2012/CR-2dcontext-20121217/#dom-context-2d-drawcustomfocusring

""Inform the user", as used in this section, could mean calling a system accessibility API, which would notify assistive technologies such as magnification tools. To properly drive magnification based on a focus change, a system accessibility API driving a screen magnifier needs the bounds for the newly focused object. The methods above are intended to enable this by allowing the user agent to report the bounding box of the path used to render the focus ring as the bounds of the element element passed as an argument, if that element is focused, and the bounding box of the area to which the user agent is scrolling as the bounding box of the current selection."

Comment 11

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #10)
> (In reply to Trevor Saunders (:tbsaunde) from comment #9)
> > (In reply to alexander :surkov from comment #7)
> > > Personally I didn't like this API and I did same points as Trevor did and it
> > > seems others more or less agreed on them. But we don't have anything better
> > 
> > its not our job to invent APis for other people.
> 
> Mozilla people are generally involved into API designing process. If there
> are objections then it's more productive to come with ideas rather than
> denial.

I don't disagree that its nice to do when you can, but I don't think it should be requirement for blocking things.

> >  The API they want isn't
> > acceptible, so they can suggest another one.
> 
> The API was accepted by Chrome and as Rik says IE team is going to implement
> it.

that's sad

> > > and I personally don't have time/passion to get into the approach deeper to
> > > invent something nicer. So my position is as long as Rik works and Mozilla
> > 
> > hit regions look pretty reasonable imo.
> 
> I think I don't follow the idea, how is it connected with accessibility
> APIs? 

read http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-addhitregion
 ?

> > > makes mostly review-only job then I think we just let the approach in
> > > Firefox. After all this makes the web a bit more accessible.
> > 
> > I don't think we should take every patch that makes one thing better and
> > breaks other stuff.
> 
> the method shouldn't really break any stuff if it's used properly.

the only case you can use it and not break anything is the case in which it is a nop.  That is you can only not break things if your path on the canvas is the same as the existing bounds of the element, in which case what is the point?

> > (In reply to Rik Cabanier from comment #6)
> > > During discussion on the canvas mailing list and the canvas a11y meetings,
> > 
> > no, its pretty clear that's false read
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> > element.html again, please don't make me go digging through my irc logs for
> > hixi saying the same thing while you were there...
> > 
> > > it is clear that this API sets the bounds in the a11y DOM.
> > > This is how it's implemented in Chrome and how it will be implemented in IE.
> > 
> > then I guess there violating the spec in addition to being insane...
> 
> what spec violation you talk about? reading
> http://www.w3.org/TR/2012/CR-2dcontext-20121217/#dom-context-2d-
> drawcustomfocusring
> 
> ""Inform the user", as used in this section, could mean calling a system
> accessibility API, which would notify assistive technologies such as
> magnification tools. To properly drive magnification based on a focus
> change, a system accessibility API driving a screen magnifier needs the
> bounds for the newly focused object. The methods above are intended to
> enable this by allowing the user agent to report the bounding box of the
> path used to render the focus ring as the bounds of the element element
> passed as an argument, if that element is focused, and the bounding box of
> the area to which the user agent is scrolling as the bounding box of the
> current selection."

quoting from http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring

   "Inform the user", as used in this section, does not imply any persistent state change. It could mean, for instance, calling a system accessibility API to notify assistive technologies such as magnification tools so
   that the user's magnifier moves to the given area of the canvas. However, it does not associate the path with the element, or provide a region for tactile feedback, etc. To persistently associate a region with
   information provided to accessibility tools, use the addHitRegion() API."

Comment 12

[Rik Cabanier]

(In reply to Trevor Saunders (:tbsaunde) from comment #11)
> quoting from
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> element.html#dom-context-2d-drawsystemfocusring
> 
>    "Inform the user", as used in this section, does not imply any persistent
> state change. It could mean, for instance, calling a system accessibility
> API to notify assistive technologies such as magnification tools so
>    that the user's magnifier moves to the given area of the canvas. However,
> it does not associate the path with the element, or provide a region for
> tactile feedback, etc. To persistently associate a region with
>    information provided to accessibility tools, use the addHitRegion() API."

Ian changed that text yesterday after you talked to him. See: https://github.com/w3c/html/commit/2728a6de9219617dcc51c4160819d262e1dc8ba1
At this point, the a11y people, Chrome and IE are in agreement on the text in the w3 version of the spec.

Comment 13

[Trevor Saunders (:tbsaunde)]

(In reply to Rik Cabanier from comment #12)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> > quoting from
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> > element.html#dom-context-2d-drawsystemfocusring
> > 
> >    "Inform the user", as used in this section, does not imply any persistent
> > state change. It could mean, for instance, calling a system accessibility
> > API to notify assistive technologies such as magnification tools so
> >    that the user's magnifier moves to the given area of the canvas. However,
> > it does not associate the path with the element, or provide a region for
> > tactile feedback, etc. To persistently associate a region with
> >    information provided to accessibility tools, use the addHitRegion() API."
> 
> Ian changed that text yesterday after you talked to him. See:
> https://github.com/w3c/html/commit/2728a6de9219617dcc51c4160819d262e1dc8ba1

yes, clarifying what the spec already said.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #11)

> > the method shouldn't really break any stuff if it's used properly.
> 
> the only case you can use it and not break anything is the case in which it
> is a nop.  That is you can only not break things if your path on the canvas
> is the same as the existing bounds of the element, in which case what is the
> point?

iirc Chrome implementation changes a11y boundaries for any given element (not necessary focused one). Also it just changes boundaries, all you can get as consequence is elements overlapping and possible hit testing conflict (like who's on top) but it doesn't seem really breaking the things

> quoting from
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> element.html#dom-context-2d-drawsystemfocusring

it's sad but at some point whatwg and w3c specs got out of sync here

Comment 15

[alexander :surkov (:asurkov)]

reopen until we are on the same page

Comment 16

[Rik Cabanier]

(In reply to alexander :surkov from comment #14)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> 
> > > the method shouldn't really break any stuff if it's used properly.
> > 
> > the only case you can use it and not break anything is the case in which it
> > is a nop.  That is you can only not break things if your path on the canvas
> > is the same as the existing bounds of the element, in which case what is the
> > point?
> 
> iirc Chrome implementation changes a11y boundaries for any given element
> (not necessary focused one). 

Yes. That was a feature that was Dominic proposed. We discussed it at length so it is going to end up in the Canvas spec.
I will make that change in mozilla as well (once this lands of course)

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What info do you need from me? Are you asking me to resolve this dispute between Trevor, Alex and yourself?

I do have one piece of feedback on the patch. I told you to do the wrong thing by using a property on the frame, sorry. The property should actually live on the element (via nsINode::Set/GetProperty) so that it survives reconstruction of the frame.

Comment 18

[Rik Cabanier]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #17)
> What info do you need from me? Are you asking me to resolve this dispute
> between Trevor, Alex and yourself?

Maybe :-)
It seems like we're stuck. What is usually done in this situation?

> I do have one piece of feedback on the patch. I told you to do the wrong
> thing by using a property on the frame, sorry. The property should actually
> live on the element (via nsINode::Set/GetProperty) so that it survives
> reconstruction of the frame.

OK. I will update the patch.

Comment 19

[alexander :surkov (:asurkov)]

(In reply to Rik Cabanier from comment #18)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #17)
> > What info do you need from me? Are you asking me to resolve this dispute
> > between Trevor, Alex and yourself?
> 
> Maybe :-)
> It seems like we're stuck. What is usually done in this situation?

There's no receipt. I think I need to look it to get an own opinion on it. It seem like we should get more discussion on the issue.

Comment 20

[Rik Cabanier]

(In reply to alexander :surkov from comment #19)
> 
> There's no receipt. I think I need to look it to get an own opinion on it.
> It seem like we should get more discussion on the issue.

Thanks!
I don't love the current methods either but:
- they are simple to use for authors
- they are simple to implement for browser vendors
- 2 other browser vendors approve and one wants to ship it (https://code.google.com/p/chromium/issues/detail?id=331923)

Comment 21

[alexander :surkov (:asurkov)]

Both spec have hit regions feature which is supposed to define boundaries of the element's representation in canvas. So as long as you do addHitRegion then you are supposed to associate a path with the element boundary. Neither spec doesn't say that explicitly but it looks like implicit consequence of:

"A control is just a reference to an Element node, to which, in certain conditions, the user agent will route events, and from which the user agent will determine the state of the hit region for the purposes of accessibility tools. (The control is ignored when it is not a descendant of the canvas element.)"

I agree that the drawn focus rect should correspond to elements boundaries at some precision. But if we exposed a focus rect as element boundaries then we run into collision when hit regions were used also (it's not clear who wins). On the another hand if focus is not drawn at all (for example no focus boundary in mouse click mode) then it might feel not right that element boundaries are rect of not existing focus. That's quite similar to Google's trick: if element is not focused then associate the given path with element boundaries. It feels hacky.

So shortly as long as we have a standard way to define element boundaries in canvas then I would prefer to follow it rather than try to fit drawFocus method to define element boundaries.

Rik, what do you think about hit region stuff? It should have same two benefits you mentioned (simple for authors and implementers). If we add "it's less confusing than drawFocus spec" item then it probably overweight the 3d item.

Comment 22

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #14)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> 
> > > the method shouldn't really break any stuff if it's used properly.
> > 
> > the only case you can use it and not break anything is the case in which it
> > is a nop.  That is you can only not break things if your path on the canvas
> > is the same as the existing bounds of the element, in which case what is the
> > point?
> 
> iirc Chrome implementation changes a11y boundaries for any given element
> (not necessary focused one). Also it just changes boundaries, all you can

How do you know which to change the boundaries for if not the one passed in?

> get as consequence is elements overlapping and possible hit testing conflict
> (like who's on top) but it doesn't seem really breaking the things

sure, all it can break is what it touches (boundary stuff) on the other hand the boundary setting stuff basically can't be used correctly.

> 
> > quoting from
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> > element.html#dom-context-2d-drawsystemfocusring
> 
> it's sad but at some point whatwg and w3c specs got out of sync here

and the wonderful thing about specs is how many of them there are to choose between ;/

(In reply to Rik Cabanier from comment #20)
> (In reply to alexander :surkov from comment #19)
> > 
> > There's no receipt. I think I need to look it to get an own opinion on it.
> > It seem like we should get more discussion on the issue.
> 
> Thanks!
> I don't love the current methods either but:
> - they are simple to use for authors
> - they are simple to implement for browser vendors

ignoring correctness makes most things simple.

> - 2 other browser vendors approve and one wants to ship it
> (https://code.google.com/p/chromium/issues/detail?id=331923)

I think Dominic want's to do something that solves his problem, but doesn't care what that is.

(In reply to alexander :surkov from comment #21)
> Both spec have hit regions feature which is supposed to define boundaries of
> the element's representation in canvas. So as long as you do addHitRegion
> then you are supposed to associate a path with the element boundary. Neither
> spec doesn't say that explicitly but it looks like implicit consequence of:

hrm, I thought that it was pretty explicit, but in any case if js is going to provide boundaries for accessibles I'd expect it would be providing a path.

> I agree that the drawn focus rect should correspond to elements boundaries

I think everyone thinks that's a reasonable goal.

> at some precision. But if we exposed a focus rect as element boundaries then
> we run into collision when hit regions were used also (it's not clear who
> wins). On the another hand if focus is not drawn at all (for example no
> focus boundary in mouse click mode) then it might feel not right that
> element boundaries are rect of not existing focus. That's quite similar to
> Google's trick: if element is not focused then associate the given path with
> element boundaries. It feels hacky.

yeah, that's more or less what I've been arguing all along.

> So shortly as long as we have a standard way to define element boundaries in
> canvas then I would prefer to follow it rather than try to fit drawFocus
> method to define element boundaries.

I'm not sure off hand if its in the spec, but atleast in gecko I think there's already a way.  I'd expect that even though the frames for the content under the canvas aren't rendered layout computes there bounds.  So presumably you can apply css to those elements and position them where you like.

Comment 23

[Rik Cabanier]

(In reply to alexander :surkov from comment #21)
> Both spec have hit regions feature which is supposed to define boundaries of
> the element's representation in canvas. 
FWIW the W3 version is going to remove hit regions

> So as long as you do addHitRegion
> then you are supposed to associate a path with the element boundary. Neither
> spec doesn't say that explicitly but it looks like implicit consequence of:
> 
> "A control is just a reference to an Element node, to which, in certain
> conditions, the user agent will route events, and from which the user agent
> will determine the state of the hit region for the purposes of accessibility
> tools. (The control is ignored when it is not a descendant of the canvas
> element.)"
> 
> I agree that the drawn focus rect should correspond to elements boundaries
> at some precision. But if we exposed a focus rect as element boundaries then
> we run into collision when hit regions were used also (it's not clear who
> wins). 
We can define that if you set a hit region for a control, the focus for that control is drawn automatically.

> On the another hand if focus is not drawn at all (for example no
> focus boundary in mouse click mode) then it might feel not right that
> element boundaries are rect of not existing focus. That's quite similar to
> Google's trick: if element is not focused then associate the given path with
> element boundaries. It feels hacky.

I agree it feels a bit strange. However, Rich from IBM has tested Google's implementation and believes that it works well.

> So shortly as long as we have a standard way to define element boundaries in
> canvas then I would prefer to follow it rather than try to fit drawFocus
> method to define element boundaries.
> 
> Rik, what do you think about hit region stuff? It should have same two
> benefits you mentioned (simple for authors and implementers). If we add
> "it's less confusing than drawFocus spec" item then it probably overweight
> the 3d item.

Well, addHitRegion seems more involved to implement for authors and much more for browser vendors. 
For instance:
- The cursor to use when the mouse is over this region
- The ID of the parent region, for purposes of navigation by accessibility tools and for cursor fallback (seems like that should be DOM order)

At this point, I'm mostly interested in having a minimum level of support for a11y to canvas. Hit regions are nice but I have not seen any interest from the browser vendors.

Comment 24

[alexander :surkov (:asurkov)]

hit regions as I understand it is basically a grid of active zones, these zones are mutually connected to elements so for example if the AT makes doAction on the element accessible then its hit region gets clicked and all visual stuff just works, on the another hand if the hit region gets clicked then click is redirected to the element so it get activated and all a11y events are properly fired.

DrawFocus method is rather complimentary visual thing for hit regions idea. Thus I'm interesting why w3c wants to remove hit regions since it's not clear how to organize otherwise the chat between element and its canvas representation.

What concerns to implementation then we could go by steps, for example, as a first approach implement addHitRegion method that associates a path with element accessible boundaries. That's quite similar to what you did already.

(In reply to Rik Cabanier from comment #23)

> >That's quite similar to
> > Google's trick: if element is not focused then associate the given path with
> > element boundaries. It feels hacky.
> 
> I agree it feels a bit strange. However, Rich from IBM has tested Google's
> implementation and believes that it works well.

I'm pretty sure it works, I think our concerns were rather about design and as long as we agree that it can be improved then we could work on it.

Comment 25

[Rik Cabanier]

(In reply to alexander :surkov from comment #24)
> hit regions as I understand it is basically a grid of active zones, these
> zones are mutually connected to elements so for example if the AT makes
> doAction on the element accessible then its hit region gets clicked and all
> visual stuff just works, on the another hand if the hit region gets clicked
> then click is redirected to the element so it get activated and all a11y
> events are properly fired.
> 
> DrawFocus method is rather complimentary visual thing for hit regions idea.
> Thus I'm interesting why w3c wants to remove hit regions since it's not
> clear how to organize otherwise the chat between element and its canvas
> representation.

The reason we want to remove it is because there are no implementations or indication that anyone is going to tackle them. Also, hit regions need path objects and those are not implemented either (and imho contain a several incorrect methods.

Focus rings can offer basic a11y features. They are by no means perfect.

> What concerns to implementation then we could go by steps, for example, as a
> first approach implement addHitRegion method that associates a path with
> element accessible boundaries. That's quite similar to what you did already.

Almost. In addition to the path, there's also the clipping region and the current CTM. They are missing from hit regions.
Hit regions also don't specify what happens if the element is removed and ignore the DOM order of the shadow tree.

I think a lot more work is needed to make them happen (+ it will be quite a bit of implementation work)

> 
> (In reply to Rik Cabanier from comment #23)
> 
> > >That's quite similar to
> > > Google's trick: if element is not focused then associate the given path with
> > > element boundaries. It feels hacky.
> > 
> > I agree it feels a bit strange. However, Rich from IBM has tested Google's
> > implementation and believes that it works well.
> 
> I'm pretty sure it works, I think our concerns were rather about design and
> as long as we agree that it can be improved then we could work on it.

I think what I mentioned in my previous email would work: if an element has an associated hit region, drawFocusIfNeeded would become a no-op. That way the API will not interfere.

Comment 26

[alexander :surkov (:asurkov)]

(In reply to Rik Cabanier from comment #25)

> > Thus I'm interesting why w3c wants to remove hit regions since it's not
> > clear how to organize otherwise the chat between element and its canvas
> > representation.
> 
> The reason we want to remove it is because there are no implementations or
> indication that anyone is going to tackle them.

I think Mozilla could adopt hit regions concept

> Also, hit regions need path
> objects and those are not implemented either

are you talk about 'options' object passed as an argument to addHitRegion?

>  (and imho contain a several
> incorrect methods.

it shouldn't be necessary to implement it in whole, we could go with path and element for the start for example

> Focus rings can offer basic a11y features. They are by no means perfect.

I think I would feel better if drawFocus didn't define accessible boundaries but rather we had an extra method for this. But that's not even in standard.

> > What concerns to implementation then we could go by steps, for example, as a
> > first approach implement addHitRegion method that associates a path with
> > element accessible boundaries. That's quite similar to what you did already.
> 
> Almost. In addition to the path, there's also the clipping region and the
> current CTM. They are missing from hit regions.

how is drawFocus supposed to deal with clipping regions? What CTM is?

> Hit regions also don't specify what happens if the element is removed and
> ignore the DOM order of the shadow tree.

I can see there's bunch of spec works before hit regions is in good shape but we could do what's reasonable. We can wrap it by pref and pretend we do a prototype.

Personally I don't see any benefits of having hit region with no element from a11y perspective. So on implementation layer if we connected hit region object with frame then we're all set, i.e. hit regions is alive till frame is alive. This approach has pitfalls but it's worth to consider it.

> I think a lot more work is needed to make them happen (+ it will be quite a
> bit of implementation work)

It's a longer way of course but we can try to keep it short as possible and finally and what's important we should end up with less confusing API. Maybe we could convince Google to reconsider their approach.

Comment 27

[Rik Cabanier]

(In reply to alexander :surkov from comment #26)
> (In reply to Rik Cabanier from comment #25)
> 
> > > Thus I'm interesting why w3c wants to remove hit regions since it's not
> > > clear how to organize otherwise the chat between element and its canvas
> > > representation.
> > 
> > The reason we want to remove it is because there are no implementations or
> > indication that anyone is going to tackle them.
> 
> I think Mozilla could adopt hit regions concept
> 
> > Also, hit regions need path
> > objects and those are not implemented either
> 
> are you talk about 'options' object passed as an argument to addHitRegion?

Path object is defined here: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects


> 
> >  (and imho contain a several
> > incorrect methods.
> 
> it shouldn't be necessary to implement it in whole, we could go with path
> and element for the start for example
> 
> > Focus rings can offer basic a11y features. They are by no means perfect.
> 
> I think I would feel better if drawFocus didn't define accessible boundaries
> but rather we had an extra method for this. But that's not even in standard.

We talked about that, but since that method would take the same parameters as drawFocusIfNeeded, it was decided to keep it together.
Someone also mentioned that we have to give developers an incentive to develop for accessibility. If they add support for focus, we get a11y for free.

> > > What concerns to implementation then we could go by steps, for example, as a
> > > first approach implement addHitRegion method that associates a path with
> > > element accessible boundaries. That's quite similar to what you did already.
> > 
> > Almost. In addition to the path, there's also the clipping region and the
> > current CTM. They are missing from hit regions.
> 
> how is drawFocus supposed to deal with clipping regions? What CTM is?

From the spec: 
The focus ring ... should be subject to the clipping region. (The effect of transformations is described above and varies based on which path is being used.)

> 
> > Hit regions also don't specify what happens if the element is removed and
> > ignore the DOM order of the shadow tree.
> 
> I can see there's bunch of spec works before hit regions is in good shape
> but we could do what's reasonable. We can wrap it by pref and pretend we do
> a prototype.
> 
> Personally I don't see any benefits of having hit region with no element
> from a11y perspective. So on implementation layer if we connected hit region
> object with frame then we're all set, i.e. hit regions is alive till frame
> is alive. This approach has pitfalls but it's worth to consider it.
> 
> > I think a lot more work is needed to make them happen (+ it will be quite a
> > bit of implementation work)
> 
> It's a longer way of course but we can try to keep it short as possible and
> finally and what's important we should end up with less confusing API. Maybe
> we could convince Google to reconsider their approach.

Can you provide your feedback to the public-canvas mailing list?

Comment 28

[alexander :surkov (:asurkov)]

(In reply to Rik Cabanier from comment #27)

> > > Also, hit regions need path
> > > objects and those are not implemented either
> > 
> > are you talk about 'options' object passed as an argument to addHitRegion?
> 
> Path object is defined here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> element.html#path-objects

Oh, we could go with current path if that's acceptable for canvas authors

> > I think I would feel better if drawFocus didn't define accessible boundaries
> > but rather we had an extra method for this. But that's not even in standard.
> 
> We talked about that, but since that method would take the same parameters
> as drawFocusIfNeeded, it was decided to keep it together.
> Someone also mentioned that we have to give developers an incentive to
> develop for accessibility. If they add support for focus, we get a11y for
> free.

Actually it's a good point (lesser work and less take care about). But drawFocusIfNeeded name doesn't make it evident that method makes something special for a11y so potentially the author could run into problems if he didn't wanted to change element boundaries or if he wanted to keep element boundaries different from focus rect.

> > > Almost. In addition to the path, there's also the clipping region and the
> > > current CTM. They are missing from hit regions.
> > 
> > how is drawFocus supposed to deal with clipping regions? What CTM is?
> 
> From the spec: 
> The focus ring ... should be subject to the clipping region. (The effect of
> transformations is described above and varies based on which path is being
> used.)

I think I miss the point here, would it resolve the issue if we hit regions had similar wording?

> > It's a longer way of course but we can try to keep it short as possible and
> > finally and what's important we should end up with less confusing API. Maybe
> > we could convince Google to reconsider their approach.
> 
> Can you provide your feedback to the public-canvas mailing list?

Sure. I just need to figure out benefits and disadvantages of either approach. I have some knowledge lack of the canvas so I rely on your opinion.

Comment 29

[Rik Cabanier]

(In reply to alexander :surkov from comment #28)
> (In reply to Rik Cabanier from comment #27)
> 
> > > > Also, hit regions need path
> > > > objects and those are not implemented either
> > > 
> > > are you talk about 'options' object passed as an argument to addHitRegion?
> > 
> > Path object is defined here:
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-
> > element.html#path-objects
> 
> Oh, we could go with current path if that's acceptable for canvas authors

True. It's unclear if the current path includes the current CTM but we could refine the text.
 
> > > I think I would feel better if drawFocus didn't define accessible boundaries
> > > but rather we had an extra method for this. But that's not even in standard.
> > 
> > We talked about that, but since that method would take the same parameters
> > as drawFocusIfNeeded, it was decided to keep it together.
> > Someone also mentioned that we have to give developers an incentive to
> > develop for accessibility. If they add support for focus, we get a11y for
> > free.
> 
> Actually it's a good point (lesser work and less take care about). But
> drawFocusIfNeeded name doesn't make it evident that method makes something
> special for a11y so potentially the author could run into problems if he
> didn't wanted to change element boundaries or if he wanted to keep element
> boundaries different from focus rect.

Yes, we talked about that before: http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0018.html
The issue was that the API would become too verbose :-)
 
> > > > Almost. In addition to the path, there's also the clipping region and the
> > > > current CTM. They are missing from hit regions.
> > > 
> > > how is drawFocus supposed to deal with clipping regions? What CTM is?
> > 
> > From the spec: 
> > The focus ring ... should be subject to the clipping region. (The effect of
> > transformations is described above and varies based on which path is being
> > used.)
> 
> I think I miss the point here, would it resolve the issue if we hit regions
> had similar wording?

I don't think it can. Hit regions are not aware of the graphics state. They are a separate DOM that is layered on top of the canvas.

> > > It's a longer way of course but we can try to keep it short as possible and
> > > finally and what's important we should end up with less confusing API. Maybe
> > > we could convince Google to reconsider their approach.
> > 
> > Can you provide your feedback to the public-canvas mailing list?
> 
> Sure. I just need to figure out benefits and disadvantages of either
> approach. I have some knowledge lack of the canvas so I rely on your opinion.

Comment 30

[Rich Schwerdtfeger]

The Canvas specification discusses clipping regions and everything in canvas is clipped to the bounds of the canvas object. The drawFocusIfPossible method will clip to the clipping regions defined for the canvas object. As for the accessibility API mapping you don't want to clip that. Accesibility API do not compensate for obscurity resulting from the clipping region. 

Draw focus is clipped the same way any drawing function is clipped on canvas. I don't know why there is something special here. 

Hit regions are not implemented in canvas today. If you have the capability to have hit testing why would you not bind the locations to elements in fallback content which would also recieve keyboard focus. You want to be able to route the same mouse and keyboard events to the same element represented on canvas. Having a separate DOM on top of canvas does not make any sense. 

Hit testing is a way off and users cannot wait for the time to implement them for access. I don't understand how the new drawFocusRingIfPossible is going to break anything. However, floating a separate DOM over the canvas element to do hit testing while using the fallback for keyboard navigation would be very bad for developers. Google should not reconsider their approach.

Comment 31

[David Bolter [:davidb] (NeedInfo me for attention)]

Dominic can you confirm if Rik's approach here will give us interop with Chromium? Alex might follow up with a longer term discussion/solution related to hit regions but I wouldn't want to block interoperability in the near term.

Comment 32

[Rik Cabanier]

(In reply to David Bolter [:davidb] from comment #31)
> Dominic can you confirm if Rik's approach here will give us interop with
> Chromium? Alex might follow up with a longer term discussion/solution
> related to hit regions but I wouldn't want to block interoperability in the
> near term.

I believe Dominic is on paternity leave so it might be a while before he responds.

Comment 33

[Dominic Mazzoni]

Yes, I'm on paternity leave for a few more weeks. David pinged me and I happened to see it, but I may be slow to respond.

My brief answer is that Rik and I have discussed it a fair amount and I'm pretty sure this will be interoperable.

If you want to see if it works on a real example, try this one I made: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ - be sure to try it with some real screen readers / magnifiers on different platforms.

Some other random notes based on this thread:

From an a11y perspective I think it'd be nice to have separate methods to set the accessible bounding box of an element, to add a hit region, and so on. However, I'm definitely persuaded by the argument that if users can get a11y for free by calling drawFocusIfNeeded, then that's a big win.

Chromium has not shipped this feature yet. It's still behind a flag. I'm happy to be persuaded. However, considering that Microsoft has already implemented something pretty close to what Rik and I have agreed on, the burden is very much on the person proposing an alternative. Or at least let's have the conversation in a forum with Microsoft to see if they're open to consider any alternatives - they're not subscribed to this bug so it seems pointless to debate it here.

Hixie and Trevor both seem to suggest that we should notify AT about the focused region only when the focus ring is actually drawn, and not otherwise. I'd like to encourage anyone to *try* to implement this and make it work with real AT. That's now how any screen reader or magnifier actually works. The browser notifies the system that focus has moved to an element, and then at some time later (maybe in the same call stack, maybe not) the AT queries that object for its bounding box. Magnifiers may repeatedly re-query that element's bounding box to see if it moved. What would you have it return when

Furthermore, AT lets you move the virtual cursor to objects without focusing them. It seems silly to me to not expose the best guess as to the accessible bounds of that object based on a call to drawFocusIfNeeded. I don't buy the argument that doing this is *worse* than doing nothing. If you try doing nothing, the user experience for a real-world example is terrible.

I don't see this as "violating the spec". If you implement the spec literally you get something that's useless with tools like ZoomText or VoiceOver. Instead, I interpreted the spec in a way that actually does something useful - and gave the feedback back to the spec authors.

If you have another proposal *that actually works in practice*, I'd love to hear it.

Comment 34

[Rich Schwerdtfeger]

I absolutely agree. Magnifiers will want to access content that is not in focus. The new version of the spec. incorporates Dominic's work here. IBM will drawFocusIfNeeded as soon as it gets the final commit in browsers. There were a number of defects on the early proposal logged by the various browser manufacturers and all have been addressed in this version of the spec. 

When it is in I will start to evangelize it externally. We needed this yesterday and I thank Dominic for his tremendous work on the enhanced design to include location setting for elements not in focus. 

We are also building test suites for this function as we speak.

Comment 35

[Trevor Saunders (:tbsaunde)]

> Chromium has not shipped this feature yet. It's still behind a flag. I'm
> happy to be persuaded. However, considering that Microsoft has already
> implemented something pretty close to what Rik and I have agreed on, the
> burden is very much on the person proposing an alternative. Or at least

fwiw the odds I'd accept a patch implementing an API like this are extremely low, so I guess you need to convince Alex to over rule me.

> let's have the conversation in a forum with Microsoft to see if they're open
> to consider any alternatives - they're not subscribed to this bug so it
> seems pointless to debate it here.

discussing it someplace else is certainly fine with me, but since you've commented more and threading across things is sort of hard I sort of have to respond :/

> Hixie and Trevor both seem to suggest that we should notify AT about the
> focused region only when the focus ring is actually drawn, and not
> otherwise. I'd like to encourage anyone to *try* to implement this and make

that's clearly crazy, so I'm not sure why you think its what I'm suggesting.  I think draw*FocusRing should have basically nothing to do with accessibility, and just draw a focus ring.  Then we should have some API for authors to specify the bounds of all of the accessibles for the canvas, for that purpose I think the API should look something like hit regions, or we could just use CSS on the shadow DOM I don't really care about the details.

> it work with real AT. That's now how any screen reader or magnifier actually
> works. The browser notifies the system that focus has moved to an element,
> and then at some time later (maybe in the same call stack, maybe not) the AT
> queries that object for its bounding box. Magnifiers may repeatedly re-query
> that element's bounding box to see if it moved. What would you have it
> return when

so instead your going to sighlently persist that information? that seems pretty unexpected.

> Furthermore, AT lets you move the virtual cursor to objects without focusing
> them. It seems silly to me to not expose the best guess as to the accessible
> bounds of that object based on a call to drawFocusIfNeeded. I don't buy the
> argument that doing this is *worse* than doing nothing. If you try doing
> nothing, the user experience for a real-world example is terrible.

not allowing authors to provide bounds for accessibles is clearly bad, but why are we trying to cram that in the side door instead of providing some real mechanism?

> I don't see this as "violating the spec". If you implement the spec
> literally you get something that's useless with tools like ZoomText or

yes, this particular API doesn't help them so what? neither does a whole bunch of the other stuff on canvas.

> If you have another proposal *that actually works in practice*, I'd love to
> hear it.

it seems like hit regions should work, you set up a hit region for things that are focusable so those things have bounds from the start and then when they get focused things will work just like when any other accessible gets focused.

Alternatively I believe that because of what's currently an implementation detail (but I'd be happy to spec) you can control the bounds of accessibles for element in the fall back content by applying CSS to them.

Comment 36

[Dominic Mazzoni]

> I think draw*FocusRing should have basically nothing to do with accessibility,
> and just draw a focus ring.

The whole reason it was proposed was to improve accessibility. The goal is to
encourage developers to use it rather than drawing their own, and as a benefit
they get accessibility that "just works" for the common cases.

I don't see why it has to be either/or. If in the future we get hit regions, we
can specify that a hit region overrides the path given using drawFocus*.

Comment 37

[alexander :surkov (:asurkov)]

btw, I filed an email to canvas a11y list http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0062.html

Comment 38

[alexander :surkov (:asurkov)]

Comment on attachment 8361982 [details] [diff] [review]
Passed focus rectangle to model + integrated it in a11y DOM

I'm cancelling review for now since we agreed to try hit regions approach prior this

Comment 39

[Rik Cabanier]

This functionality is now part of the hit regions API.
Closing bug.