[public-canvas-api] Summary of accessibility threads between 2009 - 2011

[public-canvas-api] Summary of accessibility threads between 2009 - 2011
http://lists.w3.org/Archives/Public/public-canvas-api/


Welcome to the mailing list:
http://lists.w3.org/Archives/Public/public-canvas-api/2008JanMar/0001.html

"This list is intended to serve as a dedicated thread for matters 
specific to the Canvas API and its intersection with other DOM 
interfaces and with markup."


The bulk of the work the past three years has been in advocating for 
accessibility frameworks. There has been exhaustive discussion with 
developers from several browser vendors, stemming from an early 
recommendation that the Canvas sub-tree be supported.
http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0000.html

"All accessibility frameworks are dependent on the ability to have an 
object model to provides a hierarchy that provides context to a user and 
which can provide interfaces to an assistive technology… [for example] a 
2D chart has dynamically changing data it could be replaced with an HTML 
table marked asa live region or even a grid."


Programmatic access is a conformance principle of the Web Content 
Accessibility Guidelines. Accessibility remains unresolved and an issue 
in last call procedures for HTML5 as of December 2011.
http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results
http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0457.html
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0237.html

"There are numerous accessibility issues/bugs that will need to be 
addressed, before the spec. leaves last call"


Work on resolving Canvas accessibility issues took shape in July 2009.
http://lists.w3.org/Archives/Public/public-html/2009Jul/0562.html

"It has been decided to form a task force to work on specifying 
additions to the CANVAS API, that will result in canvas content being 
natively accessible."


The merits of supporting Canvas and DOM tree interaction were discussed 
in a late 2009 accessibility call.
http://lists.w3.org/Archives/Public/public-html/2009Aug/1125.html

"[Supporting] focus for 'widgets' inside the canvas could also be 
handled via DOM, by adding a requirement that anything inside the 
canvas's DOM subtree with a tabindex must still participate in the tab 
cycle and produce focus events"


Microsoft added support for focus events inside the Canvas element 
sub-tree in their release of IE9. Other vendors are expected to follow 
suit. WebKit reviewed but eventually rejected an early patch in February 
2011.
https://bugs.webkit.org/show_bug.cgi?id=50126

"[Do not use RenderReplaced,] the best way to fix it is to make 
RenderHTMLCanvas a RenderBlock and more like a form control"


drawFocusRing, a new Canvas Context 2d method, was added to the 
specification. It's purpose to display a focus box within the canvas 
element when focus events are received.
http://www.w3.org/TR/2dcontext/#dom-context-2d-drawfocusring


Currently, no vendors support the drawFocusRing method, though there is 
broad consensus that it should be supported.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5_Canvas)


Mozilla has been discussing support for some time. Their bug report 
follows the whatwg specification, which recommends two methods: 
drawSystemFocusRing(element) and drawCustomFocusRing(element) whereas 
the w3c specification recommends one method with an optional boolean 
attribute: drawFocusRing(element, boolean).
https://bugzilla.mozilla.org/show_bug.cgi?id=540456


The drawFocusRing method was chosen over <map> element / useMap 
extensions proposed in early 2010:
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom


drawFocusRing demonstrates that the Canvas sub-tree is available for 
focus management and that the Canvas 2d path API is being exposed, in 
some manner to the system accessibility API. It's an important 
milestone. The various issues that have been discussed are catalogued on 
a W3C wiki page.
http://www.w3.org/html/wg/wiki/AddedElementCanvas


There is consensus that the useMap property, based on HTML4 <map>, 
should not be used with Canvas. The competing focus ring and caret 
tracking proposals were moved forward.
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom


Unfortunately, the group has had mixed consensus about approaching 
clickable regions in Canvas.

We've not been able to develop broad consensus. Many spec editors and 
developers who work for vendors have suggested that use cases involving 
interactive elements are not appropriate uses of HTML5 and should not be 
encouraged. There has been strong push-back suggesting that Canvas not 
be used for such cases and that SVG be used.
http://krijnhoetmer.nl/irc-logs/whatwg/20090710#l-75

"[In cases where] you only have a few active regions, then you probably 
only have a few shapes, and you can use SVG"


This lead to a lengthy series of threads about the pros and cons of SVG 
and Canvas development and the repeated suggestion that interactive 
regions in Canvas should not be encouraged (nor supported) by vendors, 
as they are better suited by retained vectors in SVG.
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0237.html
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/

"You are attempting to recreate a retained-mode API in an immediate-mode 
API. Why is 'use SVG' not sufficient for this?"


Many developers who work for vendors have simply said that SVG should be 
used instead of Canvas for interactive applications. The HTML5 editor 
has repeatedly suggested that interactive elements not be allowed within 
the Canvas sub-tree. The HTML5 has repeatedly specified that button and 
checkbox, anchor and radio be the only widget types allowed in the 
Canvas sub-tree. These specification changes were reverted in respect 
for W3C procedure. Note, the restriction is still present in the WHATWG 
specification.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element

"Transparent, but with no interactive content descendants except for a 
elements, button elements, input elements whose type attribute are in 
the Checkbox or Radio Button states, and input elements that are buttons."


Canvas developers rarely use CSS overlays to handle focus management and 
other interactivity. This is likely because of the difficult management 
of z-index ordering as well as the manual computation of bounding boxes. 
This difficulty is avoided with the drawFocusRing method of Canvas 2d, 
but no vendors currently support the method, and so CSS overlays are the 
only real-world practice available today (December 2011).

There are now multiple proposals for enabling clickable regions through 
the use of the Canvas sub-tree, DOM events, and new methods to the 
Canvas Context 2d API.. Other participants in the working group have 
gone forward with attempting to support more complex widget types.
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0214.html


These proposals, as envisioned can be expressed by two simple examples, 
both of them forward events into the Canvas sub-tree to bubble up the 
DOM in standard fashion.

( setDrawingFor proposal ):
beginElement(elem1);
... drawing operations here ...
endElement();


This proposal captures paths when fill*() and drawImage calls are made, 
starting from the time beginElement is called, and binding those paths 
to the target element in the Canvas sub-tree.

(setClickableRegion proposal)
beginPath();
... drawing operations here ...
setClickableRegion(element);


Like drawFocusRing, the setClickableRegion proposal only uses the 
current path in the Canvas state, and binds that path to the target 
element. Both of the methods are shown in the context of the input 
type=checkbox demonstration.
http://pastebin.com/gGHQdDZQ
http://lists.w3.org/Archives/Public/public-canvas-api/2011OctDec/0053.html


Outside of this active proposal there exist strong disagreements about 
text handling, whether it be rich text editing or reporting on the caret 
position and selection. The group has yet to build wide consensus that 
Canvas widgets are and will be regular staples of web application 
deployments. As such, most of the existing demonstrations of Canvas 
applications have not been accepted as Canvas use cases.
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0001.html

It's consistent to argue that HTML5 should prohibit the use of "canvas" 
to create text editors

New developments, such as Mozilla's PDF.js and the W3C Chair decision to 
include caret tracking have loosened some of these positions against 
Canvas-based complex widgets. Still, the WHATWG and W3C specifications 
remain divided as does the consensus of this working group. The lack of 
progress, and the bulk of thread-traffic on this list has been related 
to a fundamental disagreement about the scope of the Canvas element and 
the public-canvas-api list.
http://lists.w3.org/Archives/Public/public-html/2011Apr/0673.html


Should Canvas-based ARIA widgets be supported? Complex Canvas-based 
widgets are being authored. There are many examples on the web today. 
These examples work, but they are not [generally] programmatically 
accessible: testing and automation tools as well as assistive 
technologies are not granted exposure to the values they need to work. 
This is, at times, a self-imposed limitation of the developer, having 
used HTML5 Canvas instead of HTML4 and/or SVG. But, these are also 
limitations imposed by developers who work for vendors, having decided 
that they will not support Canvas accessibility on principal and in 
practice.

Where developers have jumped in, head-first, putting money and resources 
into Canvas-based user interfaces, vendors have a responsibility to 
their users. Though there are many reasonable arguments as to why 
authors should use SVG, those arguments do little to support users who 
are trying to access Canvas-based interfaces. Those users are excluded. 
The bar is simply set to high for most authors to support them. Several 
proposals have been put out in order to lower that bar. There remains a 
fundamental disagreement about whether or not the problem should be 
fixed -- about whether there is an accessibility problem.

At present, there are only minor disagreements in how to fix the problem.


-Charles