[Bug 11239] Canvas support accessible caret tracking independent of Focus Ring tracking

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239

--- Comment #48 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-10 19:55:25 UTC ---
(In reply to comment #47)
> Let me explain. When you removed the point in the process that allowed a ring
> to be wrong when it was not a descendant of the focused element things broke.

I didn't remove any such thing, it was never there. Neither your diff's
normatice text nor the CP nor the chair decision do anything that allows you to
pass a descendant of the focused element to drawFocusRing().


> Here is why it is broken:
> 
> <div role="grid" tabindex="0" aria-activedescendant="idz">
> ...
> <div role="row">
> ... <span id="idz" role="gridcell">
> ...
> </div>
> </div>
> 
> In this scenario the container grid managed the visual point of regard for the
> descendant gridcell.

And this works fine with the spec as written. You draw the path around the
grid, then call drawFocusRing() to render the focus ring around the grid (as
seen in attachment 983), and then you use setCaretSelectionPos() and give it
the x,y,w,h of the rectangle that is the "visual point of regard". In both
cases, the element you pass is the focused grid element.


> So, to separate them out we would enter a separate bug against the chairs
> decision which would remove limit drawFocusRing to only drawing rings on focus
> elements and create a separate function that is something like
> drawPointofRegard or drawNonFocusRing that only deals with managed children.

That's exactly what this decision did. It provides drawFocusRing() for the
focus, and setCaretSelectionPos() for the "visual point of regard".


> The other problem we have and which I have asked the chairs to review is the
> issue with canDrawCustom. If the system does not provide a setting for drawing
> focus rings in a certain way and the author sets the canCrawCustom flag then
> drawFocusRing does nothing to allow the author to draw the custom ring.

It doesn't do nothing. It still notifies the accessibility API. That's the
entire point of the API!


> Our change proposal required an author to configure the drawing path and the
> style before drawFocusRing was called. If the system did not have a feature
> that drew focus rings for the element type in a certain way then the custom
> ring would be drawn [...]

Which is a huge problem, because it only handles custom focus rings that can be
drawn with a single stroke() call, which is completely inadequate. Custom focus
might be handled by just drawing the text in a different font size, by using a
variety of colours, by drawing an arrow, any number of different techniques.
The whole point of the method is that it lets you draw the focus indicator as
you want.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 10 May 2011 19:55:29 UTC