This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13578 - Argument for the approval of adding setElementPath to the Canvas 2d specification.
Summary: Argument for the approval of adding setElementPath to the Canvas 2d specific...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other All
: P3 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/mid/4E1ABF6E.508030...
Whiteboard: canvas v5
Keywords: a11y, a11ytf, a11y_canvas
Depends on: 15608
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-03 05:45 UTC by HTML WG bugbot
Modified: 2012-03-28 21:47 UTC (History)
12 users (show)

See Also:


Attachments

Description HTML WG bugbot 2011-08-03 05:45:33 UTC
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.
Comment 1 Michael[tm] Smith 2011-08-04 05:01:53 UTC
mass-moved component to LC1
Comment 2 Everett Zufelt 2011-10-15 14:53:53 UTC
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.
Comment 3 Sam Ruby 2011-10-19 16:33:43 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2011-12-09 21:58:49 UTC
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.
Comment 5 Frank Olivier 2012-01-13 23:25:42 UTC
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.
Comment 6 Ian 'Hixie' Hickson 2012-01-23 23:42:55 UTC
I plan to address this as part of the path primitive feature.
Comment 7 Ian 'Hixie' Hickson 2012-02-29 22:46:44 UTC
See http://wiki.whatwg.org/wiki/Canvas#Regions for the current proposal for this.
Comment 8 Ian 'Hixie' Hickson 2012-03-28 21:47:08 UTC
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.