- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 05:45:33 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13578 Summary: Argument for the approval of adding setElementPath to the Canvas 2d specification. Product: HTML WG Version: unspecified Platform: Other URL: http://www.w3.org/mid/4E1ABF6E.5080302@jumis.com OS/Version: All Status: NEW Severity: normal Priority: P3 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: mike+html-wg-mailbot@w3.org QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org public-html-comments posting from: Charles Pritchard <chuck@jumis.com> http://www.w3.org/mid/4E1ABF6E.5080302@jumis.com Argument for the approval of adding setElementPath to the Canvas 2d specification. Proposed method: CanvasRenderingContext2d setElementPath(Node element) // attach the current path as reported by UA to assistive technology to the target element Summary: Canvas 2d shadow dom elements may receive focus() events directly and report an arbitrary path and bounding box to the UA of any shadow dom element with focus via drawFocusRing. The new method, setElementPath, would enable click events on shadow dom elements from assistive technologies which depend on screen coordinates. Related Discussion: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0143.html Action: Encourage authors to handle onclick events from within the shadow dom, and annotate clickable regions with semantic information for the AT. The following code is a -simple- example of semantic html within the canvas shadow dom. <canvas> <label for="a">First Option</label><button tabindex="10" id="a" onclick="" onfocus="" /> <label for="b">Second Option</label><button tabindex="20" id="b" onclick="" onfocus="" /> </canvas> An author could use setElementPath on labels and buttons, either way the click event and focus are handled. The code is valid html in its fallback form. Software and hardware which may benefit from setElementPath: Apple's VoiceOver for Mobile Safari, ai squared's ZoomText Magnifier, ViewPlus' IVEO Touchpad, Wacom's Bamboo tablets and Dock software. Several people on this list have advocated for improved accessibility, many of them manage educational curriculum and tutorials relating to HTML and web apps accessibility, they are a resource for encouraging use of the new method. Precedent: The HTML <label> element delegates focus and onclick events to the target element. HTML5 standardized the tabIndex attribute's use on any element; prior, only some elements could implement the focus() method. Touch events may work with multiple pointers, and on some browser implementations are only fired on elements when the onclick attribute is set (optimization technique). Users may currently navigate via tabindex or other focus mechanisms to elements in the shadow dom; this keyboard-only access may trigger an onclick event. Argument for: Introducing pointer device accessibility through onclick events is a conservative and reasonable step forward. Currently, the canvas shadow dom spec supports keyboard-only and eyes-free user interfaces. Authors are able to support simple pointer-only interfaces with Canvas, but they are limited by the information that UA submits to the Accessibility tree. Authors are not able to support the touch-based VoiceOver of Apple's Mobile Safari. To remedy the situation, we've proposed: setElementPath(element); allowing authors to support spatially aware assistive technologies such as Apple's VoiceOver for Mobile Safari. At present: touch, pen and mouse events are capable of triggering onclick, as are focus events in the canvas shadow dom. onclick events do not require accuracy in reporting pointer coordinates, they may directly preceed or follow onfocus events. Handling of the two events is a best practice for authors in supporting input device independence. Objection: Many on this list have expressed strong reservation about using the canvas 2d api to inform accessibility apis of the screen position of html form elements contained in the canvas shadow dom. It has been suggested that: a) SVG be used instead of canvas, or b) SVG be used in addition to canvas. The reasoning has been that: a) Canvas 2d is not a retained-mode API, or b) A new API should be made in addition to Canvas 2d. Many of these arguments are best summed up by Tab Atkins Jr.: "why not use SVG... why not create a new canvas context that's better suited for this kind of thing... It appears to be a foregone conclusion that we must use the existing 2d context and patch it into working." http://lists.w3.org/Archives/Public/public-html/2011Jun/0346.html Counter-Objection: There are no browser vendors currently using SVG to create UI widgets in their software. It's unreasonable for them to expect authors to use SVG graphs when the vendors are using internal apis. Supporting SVG in addition to canvas is currently impractical for most authors. "Retained-mode APIs can be simpler to use, because the API does more of the work for you ... [on] the other hand, they are often less flexible, because the API imposes its own scene model. Also, a retained-mode API can have higher memory requirements, because it needs to provide a general-purpose scene model. With an immediate-mode API, you can implement targeted optimizations." http://msdn.microsoft.com/en-us/library/ff684178(v=vs.85).aspx Canvas 2d is an immediate mode API -- functional procedures in the scripting environment manage the state of the bitmap. setElementPath does not violate the retained-mode API boundary. setElementPath does not retain data to the DOM implementation nor in the Canvas 2d implementation and it is an immediate mode call. The accessibility tree is well managed in a separate class from the DOM. The entire point of setElementPath is to update the accessibility information available to the UA and OS, so that additional software may function with interactive Canvas regions. This has been confused with "grafting" one API to another, which simply is not the case. We're discussing one API sending data to another API through a method call. setElementPath starts in the CanvasRenderingContext2d implementation, then goes through CSS transforms and positions before exposing data to the accessibility environment. Other Discussion: the -webkit-canvas and -moz-element css extensions do provide a method for canvas bitmaps to be painted onto html elements, effectively excusing authors from using the canvas tag altogether. While these are useful methods, they are non-standard and side-step the issue we're currently working with on the canvas shadow dom. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 3 August 2011 05:45:39 UTC