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

Hello Charles,

Really Really Thank you Charles.

Best Regards

On Thu, Dec 1, 2011 at 3:53 PM, Steve Faulkner <faulkner.steve@gmail.com>wrote:

> 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
>
>


-- 
Paniz Alipour