W3C home > Mailing lists > Public > public-html@w3.org > November 2011

Re: Canvas uses requiring accessibility support

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 22 Nov 2011 15:51:30 -0800
Message-ID: <CA+c2ei9y43mS7BcVVTHENw=kkcPr2vz5Esob7_LPGo7i6Qe6SA@mail.gmail.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>
On Tue, Nov 22, 2011 at 3:20 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> Hi Jonas,
> the wiki page you linked to states:
> "List some real-world examples of uses of canvas that are examples of things
> best done with canvas and not other features of HTML"
>
> Is it ok to add cases other than these, as i think most of the examples I
> find could be judged as best done with other features.
> I don't want to spend time documenting stuff that will be rejected/ignored
> as it dosn't fulfil the criteria, deemed as acceptable use cases.

That is a very good question. I agree that we shouldn't exclude things
just because we think they could/should be done using other HTML
features than canvas. I have no interest in focusing on just that
subset either.

We need to make a best effort to make accessible the parts that people
do do with canvas. In some cases people choose to use canvas even
though it could be argued that they should use something else. Our
goal should be to make the web accessible, not to make people use the
technologies that we want them to use.

We're likely to be much more successful in making said pages
accessible if we tell them "add these calls to your existing code"
than if we tell them "rewrite your entire application in this way
rather than what you're currently doing". Especially if the latter has
performance or other practical downsides which made people choose
their current approach.

That said, I don't think that it'll always be the case that the best
way for people to make their existing canvas use accessible is to add
new APIs that they can use. I know that for example in some cases
people use canvas because some CSS features don't yet work cross
browser. Adding yet other APIs in the hope that it'll allow pages to
work around shortcomings in implementations of other APIs is unlikely
to be a successful path. Much better to tell those browsers that
fixing certain CSS bugs will help the web be more accessible.

There are certainly other examples too where it's possible that the
right solution to make existing canvas deployment accessible is to
tell them to not use canvas. I *suspect* that text editors is one such
situation, but I'm prepared to be proven wrong.

But I think we won't be able to tell when this is the case before we
actually look at what's required to make the cases accessible. So IMO
the more examples of use out there that we get documented, the better
solution for accessibility we can design.

But I also want to set the expectation that just because a problem
with current canvas use is highlighted, that we'll add functions to
the CanvasRenderingContext2D interface in order to solve them, or
indeed that we'll be able to solve them at all.

But I can say that if we don't find and document a problematic
pattern, then we are very unlikely to accidentally fix it :)

However since Ian started the page, I'll leave it to him to say if he
agrees with this reasoning and if it would be ok to change the
introduction of the wiki page to reflect it.

/ Jonas
Received on Tuesday, 22 November 2011 23:52:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:41 GMT