[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.
"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://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