[Bug 13578] New: Argument for the approval of adding setElementPath to the Canvas 2d specification.

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 the QA contact for the bug.

Received on Wednesday, 3 August 2011 05:45:36 UTC