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

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

Received on Friday, 10 July 2009 09:19:43 UTC