W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: Please vote on the canvas accessibility proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 25 Feb 2010 20:23:07 +1100
Message-ID: <2c0e02831002250123u6f0b3a01yeb5986673225f07@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Thu, Feb 25, 2010 at 1:31 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 25 Feb 2010, Silvia Pfeiffer wrote:
>> > This should never be an issue -- the script typically would create
>> > this "accessible canvas" markup when it runs, only if it detects
>> > <canvas>, in which case it would just remove the fallback markup.
>> OK, you got me confused. I was thinking of a situation where there is
>> markup inside the canvas that is coupled with the drawFocusRing function
>> and thus linked with the display. Is that not practically possible?
> If that content also worked for regular legacy fallback, sure, but if it
> only really makes sense with the canvas script, then it would be better
> for the script to generate that markup dynamically and insert it into the
> <canvas> when it detects that <canvas> is supported, replacing the legacy
> fallback.

I see. So really we are saying that if there is explicit accessibility
markup inside the <canvas>, it is also supposed to be a good fallback
for legacy browsers. Otherwise it should be created by script, and
seeing as <canvas> is really only useful with script anyway, that's an
acceptable requirement. Sounds ok to me.

So, are we also saying that fallback inside the <canvas> should always
function as accessibility markup? If that is the case, then it means
that as soon as there is markup inside the <canvas>, we have support
for accessibility. End of story. don't read any further. :-)

If, however, that is not the case, then determining whether there is
markup inside the <canvas> that represents accessibility markup or
only fallback markup does indeed become a challenge. It could just be
accessible fallback markup, but not really represent what the <canvas>

To solve it, I guess one could indeed consider introducing an
attribute on the canvas to signal whether the fallback markup is also
supposed to be accessibility markup for the canvas. I don't like that
idea, though, because accessibility markup should be self-evident and
not need to be flagged. I would still think that something like the
proposed <usemap> that actually separates accessibility markup from
fallback would be a better option. As an additional bonus, we don't
even have to worry about creating the accessibility content in script
in the case where it is coupled with the drawFocusRing function. It
would just live inside the <usemap>.

Incidentally, has the definition of an invisible div with a
"aria-describedby" attribute that points to the <canvas> been
considered as a solution for accessibility markup for <canvas>?

Just my 2c of logic and curiosity.

Received on Thursday, 25 February 2010 09:24:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC