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

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

--- Comment #49 from Rich Schwerdtfeger <schwer@us.ibm.com> 2011-05-10 21:43:34 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().

If you review my change proposal you will see that I allowed a focused element
or a descendant of it to pass drawing the focus ring. The chairs did not
exclude this from the decision. 

>> 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 [details]), 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.

OK. So, I discussed that with Maciej and we agreed that overloading something
that drew a caret and selection position was a problem for authors. The second
problem with this is that you were limiting the drawing of the focus rings to a
rectangle was wrong. This was a comment that you and Josh Graham both told me
would be a problem and that we should use a drawing path. The author might want
a circle for all we know.

I would prefer to create a separate function that allows for this and this
would be part of a separate change proposal when we file a bug. This is what I
thought Maciej and I agreed to in Cupertino last Friday. 


>> 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".

Please see my point above. We are actually in violent agreement. The only
difference is that we need to do this with a function that does not limit the
drawing to a rectangle.

>> 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!

But, that is not accurate. The author could say canDrawCustom, the function
returns without drawing the focus ring and the author could create and draw an
entirely new path that does not fit the one passed to the magnifier. Is that
incorrect?


>> 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.

Having a text be a different size is not a focus "ring". This sounds like a new
requirement. Ian, the problem I want to avoid is dropping out of the function
and allowing an author to then draw a custom ring that does not match the one
generated in drawFocusRing().

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

Received on Tuesday, 10 May 2011 21:43:37 UTC