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.
Comments
You gloss over the toxic behaviour of people like Charles Pritchard and Richard Schwerdtfeger:
which has convinced some people the public-canvas-api list (and, IMHO, perhaps the W3C) isn’t an effective place to make progress on accessibility:
Here’s an alternative point of view and some background information on canvas accessibility from a W3C staffer:
Hi Mattur,
As stated at the start of the article:
I would suggest that neither Charles Pritchard or Richard Schwerdtfeger’s behaviour can be characterised as ‘toxic’, though it is easy, if motivated to do so, to highlight instances where discussions became heated. This is how Doug Shepers described it:
To be enable a more balanced view of Charles Pritchard’s behaviour I invite people to review the full archives of his correspondence on the canvas-api mailing list. Do the same for Richard Schwerdtfeger, who is one of the most influential and well respected accessibility engineers and advocates of the last 20 years, I recommend anyone who doubts that read his articles on Accessibility Strategy and Architecture or just ask around in the accessibility community.
Hi Steve,
Thanks very much for this review of the situation. A lot of us in the non W3C circles were/are confused as to what the real status of this issue was. This is very useful fir us to have at hand when planning the next 12 months.
CP
@cdspower
Charles and Richard toxic…
I don’t know of any people who have worked harder on making some of these specs more accessible, excepting Steve and a few other equally hard working folks.
The level of push back has been extraordinary. Combine this with the petty and mean spirited jabs that some of these “butter don’t melt in my mouth” types indulge in within an IRC channel that’s publicly accessible, and it’s no surprise that people trade off the foolishly polite back and forth and just bluntly say what they mean and what they feel.
And it doesn’t help when Doug gets into his lecture mode, because he sucks at it. Seriously. I think he’s well meaning, but I also don’t think he realizes that many times he jumps in when things are winding down, and then leaves everything in a brittle state.
So, mattur, you’re off the mark. Widely.
Mattur,
I understand the “hit testing and retained graphics” thread was difficult for members of the list to endure. Richard Schwerdtfeger did advise me ahead of time not to engage in the argument. My thinking was that Tab Atkins was representing the WHATWG in good faith. He was. He did. He stuck through the entire thread.
Tab’s position, similar to Doug’s was a) Use SVG or b) wait until a new graphics API is written. Doug was good enough to invite me to the SVG F2F, where Tab and I were both able to voice our positions in a more productive manner.
The conversation between Tab and I may have been better left off the mailing list. Regardless, I have a great deal of respect for him, and for the HTML5 editor, Ian Hickson. Tab Atkins was a good sport, and wrote up a summary of my position, which you can read on Bug 13176. We have some fundamental disagreements, and, lets call them professional quirks. I have no doubt that there is room for thoughtful engagement and passionate debate. Perhaps a little less heated in the future.
Thank you so much for this post as it outlines a lot of the information out there and get get confusing. Here is my overall concern with canvas, along with several other html5 components- it seems even if we do get these to be accessible, we often have to work out those kinks with not only the browsers, but also the screen reading technologies- which can be just as cumbersome. In my experience, as a developer and a disabled individual, is that the screen readers are usually one or two versions behind the browser.
Nice summary – wish I found it before I had to sort it all out myself!
I will say that the just use SVG debate may be more pie in the sky versus the reality that many people are already using canvas for many things they would have been doing in Flash (https://www.canvasdemos.com/ will give you a sense of things people are using it for) such as games or 3D where accessibility has historically not been their primary focus.
It sure would be nice if instead of “don’t do it that way” and (no offense to the hard work already done) we didn’t put our heads in the sand and we instead had a “it is possible to make these accessible, using canvas by…”.