This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
mass-moved component to LC1
Changing to importance P1 after a11y-tf bug triage meeting on 2011-10-11. It would appear that if this bug is not resolved some assistive technologies will not be able to access all UIs designed using the canvas 2d api.
Restoring priority as the deadline for objecting to initial or revised priority settings or deferrals was Sep 2, 2011: http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html Should this issue not be resolved by December 31, 2011, it can be escalated as a WG issue at that time.
What precisely is the problem this proposal is attempting to solve? It would be helpful if this wiki page (or another but with the same structure) could be filled in documenting precisely what it is that needs addressing here: http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases See also bug 13176, which seems confusingly similar.
I have written up some proposed spec text at http://www.w3.org/wiki/Canvas_hit_testing for this change; the text includes the rationale for this change.
I plan to address this as part of the path primitive feature.
See http://wiki.whatwg.org/wiki/Canvas#Regions for the current proposal for this.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: addHitRegion() Rationale: Concurred with reporter's use case.