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

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

--- Comment #37 from Maciej Stachowiak <mjs@apple.com> 2011-05-05 06:51:55 UTC ---
Hi Rich,

(In reply to comment #36)
> Ian,
> 
> I am not going to go point by point with you and waste another hour of my day
> on what was already agreed upon by the chairs. 
> 
> It is a common practice to have Rich Internet Application components manage the
> visual focus for the descendants they manage. The intent of drawFocusRing is to
> allow elements that have focus to show visible focus and for those elements to
> show the visual focus around the child that they manage. This happens in UI
> component libraries, like Dojo. 
> 
> To illustrate further, while I understand that keyboard focus is on a tree
> widget the visual focus should be on the descendant that it manages. When you
> operate a tree widget you are not visually operating on the container yet the
> author has given a visual point of regard on the managed descendant. This is
> indeed consistent with WCAG 2. Authors can then use aria-activedescendant to
> notify the assistive technology what child is the one they should operate on
> with focus. This works and it works in Chrome, Firefox, Safari, and IE. I can
> provide you numerous code examples from the Open Ajax Alliance that we will be
> using for browser testing for ARIA.

It is indeed the case that complex widgets often have a "point of regard" that
is more fine-grained than the element with focus. However, on operating systems
I am familiar with, it is not normal to draw a focus ring with the standard
system look in such a case. For example, on Mac OS X, the keyboard-active item
in a tree view is drawn selected, not with the blue glowing focus ring that
represents focus. Perhaps a new API is needed is needed for this use car, since
using drawFocusRing to indicate focus of an individual tree or grid item would
result in visually wrong behavior.

> 
> There is nothing wrong with this authoring practice and it is used extensively
> throughout the Web. Since the canvas subtree is being used to generate the
> accessibility API mapping in browsers and these are common and accepted
> authoring practices that are also accessible and supported accessibly on
> multiple browsers then canvas's drawFocusRing must support this functionality.
> 
> Now, if your concern is over the name "focus" in drawFocusRing I would support
> a name change or some clarity in its description.  

I think the problem is not just the name, but the behavior. It is actually
specified to draw a focused appearance. That is not done for
aria-activedescendant type point-of-regard items, either in Web content or in
native apps. Drawing focus rings around two separate items would violate the
Mac OS X HI guidelines.

Do you agree that this is an issue? If so, can we agree on a separate mechanism
to identify a "point of regard" that is not actually meant to be drawn with
focused appearance? If not, then I guess we will have to address it via a Last
Call comment.

-- 
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 Thursday, 5 May 2011 06:51:58 UTC