Charles Pritchard has taken the time to provide an email overview of Canvas accessibility discussions which have taken place on the public-canvas-api over the past 3 years. I have reformatted it here and added some headings, as it is an excellent resource for understanding where we have been and where we are with HTML5 canvas accessibility:
The Canvas API mailing list
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.
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.”
Accessibility remains unresolved
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:
“There are numerous accessibility issues/bugs that will need to be addressed, before the spec. leaves last call”
3 years on
Work on resolving Canvas accessibility issues took shape in July 2009.
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.
[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
Canvas element sub-tree support
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.
[Do not use RenderReplaced,] the best way to fix it is to make RenderHTMLCanvas a RenderBlock and more like a form control
Focus ring support
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.
Currently, no vendors support the drawFocusRing method, though there is broad consensus that it should be supported. 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). The drawFocusRing method was chosen over <map> element / useMap extensions proposed in early 2010. 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.
Canvas clickable regions
The various issues that have been discussed are catalogued on a W3C wiki page. 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. 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 [browser] 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.
[In cases where] you only have a few active regions, then you probably only have a few shapes, and you can use SVG
Just 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 [browser] vendors, as they are better suited by retained vectors in SVG.
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 [browser] 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.
Use of CSS overlays
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.
Proposals: 2 simple examples
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:Canvas 2d Pointer Checkbox
Other strong disagreements: the W3C and WHATWG specifications remain divided
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. 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.
Lack of progress: hindering accessibility
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. 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.