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

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

--- Comment #47 from Rich Schwerdtfeger <schwer@us.ibm.com> 2011-05-10 13:48:22 UTC ---
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.
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. DOM focus is on the grid and the active descendant is the
gridcell. When the id of the activedescendant changes a system focus change is
sent to the assistive technology which processes the new active descendant. 

This is very similar to desktop applications. Now, an author could also
implement a roving tabindex on gridcells in which case what you have would
mostly work. Now, in general active children (managed children) do not always
use system conventions for drawing a focus (Maciej's earlier point) and it
would be more intuitive to separate out this function.

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. I
don't want to start separating them out now, by making your change to eliminate
the active descendant on drawFocusRing, as it would obfuscate the error in the
next paragraph. 

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.
However, doing nothing also means that the magnifier is not notified where the
point of regard is and the low vision user will be unable to track their
location.

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 and the magnifier would be notified. If the OS did have a
feature that was applied to draw a focus ring a certain way then the user agent
would apply that styling instead. 

Does that help? If we still have a disconnect then sure I would be happy to
talk.

-- 
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 13:48:32 UTC