RE: Canvas uses requiring accessibility support

Text editing is certainly a fool's errand in canvas.

Our fallback/a11y DOM approach infers that we want authors to map their canvas UI to 'regular' dom input elements.

This means we'll have two scenarios:
[1] Canvas UI that map well to regular input elements
A canvas checkbox (http://www.htmlstack.com/checkbox/ ) is the quintessential example here. My canvas bitmap is represented by a regular checkbox. Easy.

http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_transparency.htm is another reasonable example; the input type=color element doesn't do alpha; but I could map each of the four sliders in canvas to an regular range control. Note that the canvas element would have multiple tabbable/focusable input elements in this case. (We'll have a bunch of canvas UIs that have an accessibility consideration that maps to several regular elements in the a11y dom.)

[2] Canvas UI that doesn't map well to regular input elements.
See the customize-timing-function canvas UI in http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_transitions.htm
Or http://shapecatcher.com/index.html 

These user interfaces don't match well to regular input controls (which is why the author elected to use canvas to begin with, probably). Our guidance to authors will be harder here. I think (like above in [1]) the best approach might be a canvas UI with multiple tabbable/focusable/etc input elements in the a11y dom.

To make either type [1] or [2] canvas element behave more like a regular input control, we will need the usual considerations that a input control has (it reports a size/location to screen readers/magnifiers). I think we are close with canvas accessibility, but we still need a way to report size/location to a magnifier and drive hit testing.

IMO We need a 'general purpose' hit testing solution here (to assist in author uptake) with a very simple method that allows authors to see what path/pixels are actually being set for hit testing. We spent some time at TPAC discussing this and IMO there is broad support for adding the following method (exact name TBD, of course) and behavior:

boolean setElementPath(in Element element);

I would define this as: (Additional spec text for http://dev.w3.org/html5/2dcontext/#focus-management )

When a canvas is interactive, authors should include focusable elements in the element's fallback content corresponding to each focusable part of the canvas. 

When multiple focusable elements are added, authors should use setElementPath() to set the focus ring of each individual focusable element. 
If the focus ring is not set with setElementPath(), the focus ring of a focusable element in the fallback content is the bounding rectangle of the parent canvas element. (This improves accessibility for the case where the entire canvas element represents a single interactive control (think very simple custom-drawn checkbox), and fallback element click handling is being handled entirely by the author. [The single checkbox case.])

When setElementPath() is called, the drawing path is used to form the focus ring provided that drawing path contains a closed path. The drawing path is used to form a best fit bounding rectangle in screen coordinates. The bounding rectangle and drawing path may be used to enhance accessibility properties [ARIA] for the targeted element.

User agents should use the information set by setElementPath() to create accessible user experiences. For example, a screen reader may read the fallback element's details when the user indicates interest in that region of the canvas.

The setElementPath(element) method, when invoked, must run the following steps:
1.
If the element is not a descendant of the canvas element with whose context the method is associated, then return false and abort these steps.

2.
If supporting an accessibility API, user agents may use the drawing path to form a best fit rectangle in screen coordinates and apply it to the bounding rectangle of the associated accessible object. The focus ring should be subject to the clipping region.

3.
Return true.

When the user interacts with the canvas, the user agent should forward the event to the fallback element.

If two or more elements have overlapping paths (set via setElementPath()) the last call to setElementPath() wins.



-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Wednesday, November 23, 2011 6:11 PM
To: Jonas Sicking
Cc: Steve Faulkner; HTMLWG WG
Subject: Re: Canvas uses requiring accessibility support

On Tue, 22 Nov 2011, Jonas Sicking wrote:
> 
> However since Ian started the page, I'll leave it to him to say if he 
> agrees with this reasoning and if it would be ok to change the 
> introduction of the wiki page to reflect it.

Your reasining seems about right, though it sounds like I'd be a little more ready to err on the side of "using canvas for this is just inappropriate" than you would. For example, it seems quite clear to me that trying to write a word processor in canvas, for instance, is just a fool's errand. The list of reasons why it's a bad idea are extensively documented, including in the spec itself which gives a 16-item bulleted list of reasons to not do a text editor in canvas.

Canvas has legitimate use cases, as does much of HTML, but that doesn't mean we should support _all_ use cases for _all_ features. For example, it's inappropriate to use an image map to make a checkbox, and we shouldn't support such a use case for image maps. It's inappropriate to use <h1>s to make a list, and we shouldn't support that use case for headings. It's inapproriate to use <span style=""> to make a coloured ASCII art penguin, and we shouldn't support that use case for <span>. We should only support use cases for elements where they make sense.

Filling out the "Limitations" section of the wiki page would be hugely helpful in determining how we can improve canvas:

   http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases

Note: Just putting links in the use cases section is not sufficient.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 24 November 2011 03:22:38 UTC