- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 14 Jul 2011 19:04:47 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, David Singer <singer@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <hober0@gmail.com>, Canvas <public-canvas-api@w3.org>
On 7/14/2011 1:40 PM, Jonas Sicking wrote: > For what it's worth, I do think that while a lot of these are > "invalid" uses of canvas, I think we need to have a better > accessibility story for them. In particular, one situation which is > common, and is likely to remain common, is JS libraries, such as > processing.js which output to canvas. We can and should improve the > SVG DOM to attract more people, but I suspect there will always be a > group of people that choose to use canvas anyway due to better > performance or other reasons. I've provided emscripten as another example; I think it goes side by side with the processing.js example you've given. I've also agree with the performance-or-other-reasons argument. David Singer made some similar statements: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0179.html > Ideally setting the area covered by one of these regions should be > easy to set while performing one or more drawing operations. > > Adding something like: > > interface CanvasRenderingContext2D { > ... > void setDrawingFor(in Element target); > void clearRegionFor(in Element target); > void clearAllRegions(); > ... > }; > > might go a long way API wise. The clearRegionFor would remove any Something similar was proposed by Richard Schwerdtfeger in March 2011: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0090.html http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0090/Canvas2DClickableRegion.html#focus-management Search for: setClickableRegion in the api change proposal Richard's proposal has setLastDrawn and lacks clearing methods. setLastDrawn is a "light" version of z-index. We have since folded setLastDrawn into the clickable region method as an optional z-index attribute. Richard's take, I believe, was that path clearing methods are not necessary as the elements may simply be removed from the DOM or otherwise cleared by setting the drawing path to an empty path. So, there are two methods to clear the region data from the accessibility tree. > Once a region has been associated with an element, it would act > similarly to how a<label> acts. So clicking that region would > dispatch a "click" event to the element and hovering it would dispatch > "mouseover" etc. > > There are of course lots of unanswered questions, such as if focus > outlines should automatically be drawn by the UA if an element with an > associated region is focused. But the above might be a start. We have drawFocusRing for that, the author should set an onfocus event on the DOM element and run drawFocusRing as appropriate. There are times when the author may also use aria labeling, such as aria-activedescendant. The author may also choose to manage setCaretSelectionRect You pointed out there could be some conflicts between those two methods: http://lists.w3.org/Archives/Public/public-html/2011Apr/0748.html Generally speaking, such conflicts are handled by the UA and AT; ATs for instance, have options to prioritize what they follow with mouse, caret and focus. -Charles
Received on Friday, 15 July 2011 02:05:14 UTC