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

Why doesn't the <canvas> element allow the @usemap attribute? Event handlers
could then be attached to a canvas via <map> areas. Such client-side image
maps would also make canvas more accessible.

On Fri, Jul 10, 2009 at 2:18 AM, Joshue O Connor <joshue.oconnor@cfit.ie>wrote:

> Lachlan Hunt wrote:
> > Joshue O Connor wrote:
> >> Lachlan Hunt wrote:
> >>> Joshue O Connor wrote:
> >>>> This kind of thing seems to me a ridiculous level of complexity and a
> >>>> retrograde step in web development.
> >>> Rather than simply rejecting the idea outright, could you elaborate on
> >>> specifically what was wrong with the techniques I described?
> >>
> >> Its clever, in that - yes it /could/ work and fair play for you having
> >> the smarts for coming up with it. However, its just (and no slight on
> >> you) very complicated. In particular if you look at this through the
> >> lens of an author who would have to do the /extra/ steps you describe to
> >> make stuff accessible. They just won't bother. When a declarative markup
> >> language is used it has inherent properties that are recognised by AT.
> >> <canvas>  etc is just a drawing API with no such properties - any
> >> solution will be a hack really.
> >
> > Indeed.  But the advantage of looking at solutions that use nothing more
> > that what we already have available today is that it helps to identify
> > possible concepts to build upon, specific issues to address and, if
> > anything we have already works well, to avoid needlessly re-inventing
> > the wheel.
>
> True but it needs to be very simple, and ideally the language of the
> spec should support and enable the creation of accessible content
> automagically - right? The idea that there are better solutions out
> there is a common mantra in these parts, <canvas> is one of our greatest
> challenges.
>
> >> Yes, the WG could strongly advocate the use of<canvas> for nothing
> >> other than eye candy or pretty pictures. In fact the spec already pretty
> >> much states that it shouldn't be used when there is a better solution -
> >> not that many will listen as the genie is already out.
> >
> > This doesn't really sound like a solution to the problems, so much as it
> > sounds like trying to stop a wave coming up the beach by standing in the
> > water in front of it.
>
> Yes, but it is the current advice in the spec. [1]
>
> <quote>
> Authors should not use the canvas element in a document when a more
> suitable element is available.
> </quote>
>
> That could become the spec equivalent of "Cigarettes may damage your
> health" - in other words redundant verbiage that may as well say "Smoke
> 'em if you got 'em". FWIW <canvas> is really interesting for what it
> does - and I have seen some clever things done with it - it is just very
> flawed (in terms of inherent semantics) and these flaws could seriously
> effect PWDs who will not be able to access <canvas> content at all
> without some committed developer magic, care and attention. If the
> solution ain't elegant then the examples in the wild that we will be
> looking at in a few years time to support the retention of <canvas> in
> HTML 6 will be pretty poor...sound familiar?
>
>  I just don't think it will be too successful.  It
> > seems clear that people are going to keep finding lots of innovative
> > ways to use canvas to solve their problems if they perceive it as having
> > some advantage over the alternatives.  So instead of pushing against
> > developers, I think it's better to work with them to improve the tools
> > they want to use.
> >
> > John Foliot wrote:
> >> Lachlan Hunt wrote:
> >>> 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.
> >>
> >> What size is this stretched image? 1024 X 768? 800 X 600? Something
> else?
> >> How are you going to know?
> >
> > Making two elements the same size and positioning one on top of the
> > other isn't really that hard.  Working within the constraints of using
> > only existing tools, that was just a hack to workaround the limitation
> > of canvas not having its own usemap attribute.
>
> If there was an editor that supported this kind of functionality - then
> yes it maybe wouldn't be too hard. The challenge is maybe similar to
> old school rollovers and even PDF and how you tag those documents.
> However, such as thing doesn't exist yet and I guess when you floated
> your idea - my first thought was of coming up with image map
> co-ordinates that would scale as browser content re-sizes, then mapping
> all that to the various <canvas> elements, never mind the heavy reliance
> on scripting to capture/emulate onclick events. In short, if there was
> an editor that could do all this stuff and adopt a constraints based
> approach that was weighted in favour of the creation of accessible
> content ( promoted the author to add these image maps and added the
> necessary scripts even if the author knows zip about JS and basically,
> not let anything out of the local host directory that was not
> accessible) - then yeah.
>
>
> > In IRC, some of us discussed a few more techniques that built on these
> > concepts to find ways of doing exactly that, including the following:
> >
> > * An API to declare active regions which can receive focus and events,
> > including both keyboard and mouse.  These could be positioned either by
> > explicitly specifying positions, or have it more automatic somehow based
> > on the areas in which the script draws. This may have some advantages
> > for authors that would otherwise have to calculate what was clicked
> > manually based on the mouse position.
>
> What about using ARIA and dynamically building a DOM?
>
> > * APIs that, while the canvas is focussed, let script take manual
> > control of navigation events and be able to respond with appropriate
> > information.
>
> Well, I am not an API author but if those things are do-able - go for
> it. However, to totally play devils advocate here if I was an author and
> I wanted to do <canvas> type stuff but I kinda _slightly_ cared about
> accessibility - if the <canvas> framework looked too complex I would
> just build all my widgets in Flash. It is also a vector based drawing
> app and while not perfect - the accessibility capabilities of Flash/Flex
> are certainly improving - and I have been impressed with some of what I
> have seen in the latest audits I have done of applications using these
> platforms.
>
> Cheers
>
> Josh
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#the-canvas-element
>
>
>
>
>
>
>