- From: James Craig <jcraig@apple.com>
- Date: Mon, 16 Nov 2009 16:28:48 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, Alexander Surkov <surkov.alexander@gmail.com>
On Nov 16, 2009, at 4:09 PM, Richard Schwerdtfeger wrote: > Mozilla expressed a concern in using tabindex inside the shadow DOM as it created issues with the layout engine. Were you suggesting using tabindex or an alternative vehicle? The challenge as I understand it is that the shadow DOM is invisible and focus in Mozilla is tied to a visual rendering. Can it work just like the proof-of-concept does, essentially rendered but not visible? I just clipped the rendering by positioning it behind the canvas, but the interaction metaphor could be the same. Not sure this is necessary, but perhaps the shadow DOM elements could just be rendered inside an invisible subview, but take focus normally. > I am not sure why you saying there is a problem with Bespin. You may in fact need a separate accessible object for each complex object in Bespin to convey the accessibility information. When I looked at Bespin it had a tool bar and a text editor with line numbers. I can see having aria-activedescendant being able to manage that albeit more work as in the case of the toolbar having a combobox. It also had dialogs and other views that could contain managed widgets. As another example, imagine a web app like a spreadsheet editor that has a data grid inside each tab of a tabset. There would need to be one active descendant (or one element with tabindex="0") for each grid and for the tablist. One active descendant for the whole canvas would not be sufficient.
Received on Tuesday, 17 November 2009 00:29:31 UTC