Re: another example of HTMl 5 canvas with interactive UI elements.

Hi lachlan,
the use of an image map is something I played with when i wrote a piece
about canvas accessibility a few weeks back:
http://www.paciellogroup.com/blog/?p=362

I have also mentioned it in respect to being a concept that could be built
upon in the bug report

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7011



Providing a duplicate of the canvas content in html may be the best solution
in circumstances where canvas is being used to represent a static
represention of data visually as in the example that ian has put forward
http://www.whatwg.org/issues/data.html even though it places the burden on
the developer to create an 'accessible version'.



The main issue I see is where canvas is being used to create interactive
interface elements, which is why i keep citing such examples as they arise.
providing developers with a method to create 'hot spots' on a canvas that
have built in focus and interaction properties may be a start. this would
provide a shortcut for developers to add interaction without them having to
think about adding extra for eaccessibility. It may be that these are
primitive objects which can have ARIA role and properties added. this is not
ideal as it would still involve bolting on additional properties.





regards

steve





2009/7/9 Lachlan Hunt <lachlan.hunt@lachy.id.au>

> Steven Faulkner wrote:
>
>> http://tools.mozilla.com/
>>
>> non mouse users get a link to a html version
>>  http://tools.mozilla.com/simple.html
>>
>> Reminds me of alternatives offered to flash content.
>>
>> We have the opportunity to work out how to allow developers to provide an
>> accessible canvas based UI controls, before users with disabilities are
>> ghettoised by the inherent inaccessibility of canvas as currently specced.
>>
>
> One relatively simple way to make that particular example accessible would
> be to make use of an image map.  The technique could work something like
> this.
>
> Overlay the canvas with a stretched transparent image of the same size has
> the canvas.  The image then needs to be associated with an image map.
>
> For each icon represented on the canvas, an associated <area> element needs
> to be created by the script with its co-ordinates set to the position of the
> corresponding icon.  Appropriate alternate text is also needed for each one.
>  When icons on the canvas are moved, the image map areas need to be
> dynamically updated also.  With each area being focussable, this would add
> support for keyboard navigation.
>
> The image and each area element would listen for and respond to events,
> such as mouse movement, clicking, and keyboard events. These events then
> trigger the appropriate animation or reorganisation of the icons.
>
> When a blurb is shown after clicking on an icon, focus would need to be
> given to it so that screen readers would be made aware of and read their
> content.
>
> I may have missed some things, as I only took a brief look at the system.
>  But it seems that, at least in this case, it's possible to get creative
> with existing features to provide an interactive and accessible mechanism,
> rather than relying on a separate alternative.  Although, in this case,
> providing the alternative as a plain table as well is useful for many users
> who would prefer not to use the canvas based approach. But it would help to
> have the table divided into the same categories as are available in the
> interactive canvas version.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html