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

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

--- Comment #33 from Charles Pritchard <chuck@jumis.com> 2011-05-03 19:11:43 UTC ---
(In reply to comment #32)
> (In reply to comment #30)
> > - 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.

I've seen this objection multiple times: what on earth are you referring to?
Focus is restricted to the shadow dom, and can only be used when the canvas
element or a descendant is in focus. Is there ambiguous wording in the CP?
There's been no change (from what I recall) in that shadow+focus dynamic from
the existing spec. It's implemented and tested by one vendor (MS) with WebKit
slowly coming on board.


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

Your position of authority does not extend so far as to declare the <canvas>
tag should not be used for visual rendering of children. This statement seems
to discount the very purpose of the canvas shadow dom and drawFocusRing. I'm
baffled by both of these replies, as you were clearly on board with
drawFocusRing in your prior drafts of HTML Living.

We're trying to promote GOOD practices, per WCAG 2.0. It'd be nice to have you
on board with that intention.

> Radio groups aren't focused, radio buttons are. This is already supported.
> 
...
> In a list box, the focus ring is drawn around the list box, not the options, so
> this is already supported.
...
> 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.

This seems to be an extension of the misunderstanding about the language in the
CP regarding "focus" on descendants of the canvas element. Yes, it's quite well
supported, and it is not a feature that the CP attempts to change.

Perhaps this is just my misunderstanding of the situation, but it seems that
both you and Richard are arguing the same point.

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

That's absurd -- this grid example is widely used in ARIA docs -- the purpose
is to allow a user to press arrow keys on their keyboard, to change focus.
There's little reason for the merits of ARIA itself to be challenged in this
post.


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

Are you disagreeing with this latter point?

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

Again, you are challenging the purpose of ARIA itself, and related, WCAG
standards. These are required by U.S. law, and their absence is an active
attempt at stifling competition. I appreciate your intent, and your role in the
community, but you are unwittingly misusing your authority as the only editor
of the HTML5 spec.

Again, I'm willing to say that I may be misunderstanding the situation -- but
by and large, these implementation mentions are directly related to
accessibility -- the primary purpose of the CP. Universal design requires
active participation from the author -- a point you seem to disagree with.
Where are your credentials in accessibility, to back these statements? At
present, your hope that the entirety of a11y can be handled without active
author involvement is misguided and arguably, under-informed.

-- 
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 19:11:48 UTC