- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 May 2011 13:41:36 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239 --- Comment #36 from Rich Schwerdtfeger <schwer@us.ibm.com> 2011-05-04 13:41:30 UTC --- 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. 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. If this is unacceptable you are welcome to open a defect post last call but the capability to support drawing of a visible focus ring or point of regard must be supported for accessibility. For the record, my job is not to promote idealistic authoring practices. My job is to ensure that authors have the tools to produce accessible solutions as consistent with their development goals as is technically possible. -- 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 Wednesday, 4 May 2011 13:41:37 UTC