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

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

--- Comment #32 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-03 18:44:10 UTC ---
(In reply to comment #30)
> - I have not tried the code change the editor has made, when I see the full
> change I will try it out. We had found defects in the prior code which did not
> run and we added commments. Please refer to the change request adapted for the
> chairs decision at it:
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html
> If the editor could adapt his changes to our code it would run and pick up the
> performance issues addressed by the editor. 

Could you be more specific? The code in the CP has multiple problems (as it in
fact admits up-front), as does the code in the spec; the code in the patch is
an attempt to address both sets of problems.


> - DrawFocusRing must be able to draw a focus ring around an element with focus
> or descendant of an element with focus.

That makes no sense (it would mean that multiple elements would be rendered as
having focus if, e.g., the <body> had focus), and is not supported by the CP. I
don't think we should be making changes unsupported by the CP, and I don't
think we should be making changes that break the API.


> Often, in rich internet applications an
> element with focus will managed visual rendering of focus for its children.

Before I go through the examples, let me just say up front that trying to
create any of these using <canvas> is simply inappropriate and that we should
absolutely be pushing back on authors who try to do such things. We should not
be promoting bad practices.

> Examples of this are grids,

In a grid, it is individual cells that would be focused, not the whole grid,
when you want the focus ring around a single cell. This is already supported.

> radio groups,

Radio groups aren't focused, radio buttons are. This is already supported.

> listboxes,

In a list box, the focus ring is drawn around the list box, not the options, so
this is already supported.

> and tree widgets. 

I don't understand why tree widgets would be a problem here. If you want the
focus ring around the whole tree widget, and you just focus the whole tree
widget, that's what you would pass as an argument. If you have a tree widget
where individual subparts get focus rings, then those are what get focused and
those should be the ones you pass in. It again seems quite well supported.


> A note to the editor:
> In the canvas subtree authors can use aria-activedescendant on one of these
> element to convey the focus location of a descendant to an assistive
> technology.
> 
> example: 
> <table role="grid" aria-activedescendant="foo">
> ...
> <tr role="row">
> <td role="gridcell" id="foo"> ... </tr>
> ...
> </table> 

There's no need to use something as complicated as ARIA for this kind of thing.
You can just use tabindex.


> - caretSelectionPos still has some problems. I don't have an issue with the
> name change or the use of a path to produce the rectangle
> -- The accessibility API mapping must step must be provided. 

I strongly disagree. This is neither supported by the CP nor necessary. We
should not be defining precise UI.


> -- The text does not address when the user agent window is moved or resized

It is unnecessary to even mention that windows exist. This is a UI
implementation issue. It's only a problem in the spec if we make the text say
how to implement UI, which we shouldn't in the first place.

-- 
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, 3 May 2011 18:44:17 UTC