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

Hi Charles, many thanks for this summary, I took the liberty of
reformatting and posting it it as its a valuable overview of where we
are and how we got here!

http://www.paciellogroup.com/blog/2011/12/html5-canvas-accessibility-discussions-2009-2011/

regards
stevef

On 1 December 2011 02:07, Charles Pritchard <chuck@jumis.com> wrote:
> [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
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Thursday, 1 December 2011 12:24:41 UTC