- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 1 Jul 2011 11:10:16 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Matt May <mattmay@adobe.com>, Cameron McCormack <cam@mcc.id.au>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On Fri, Jul 1, 2011 at 7:41 AM, Charles McCathieNevile <chaals@opera.com> wrote: > On Thu, 30 Jun 2011 03:16:18 +0200, Cameron McCormack <cam@mcc.id.au> > wrote: >> Matt May: >>> Flash uses retained-mode graphics. >> >> If Flash doesn’t support immediate mode graphics, then I’m not sure how >> it would be that the “Bespin/Skywriter canvas-as-UI problem … would have >> been reasonably well supported by the accessibility support found in >> Flash Player 8”. Would you not have had to rewrite Bespin with Flash’s >> retained mode graphics API (and thus avoiding this whole problem in the >> first place)? Isn’t this the same as people saying “rewrite your app in >> SVG”? > > No, because if you *can't* write with immediate mode, you won't. If you > *can* - as you can on the open web, using canvas, we can be reasonably > sure that *someone* (and most likely, following that a whole lot more > someones doing ever crazier things, and sometimes actually seriously) will > do so. As was the case for Skywriter/Bespin. As was the case for certain > products we have worked on at Opera. > > "Rewrite your app in SVG" is probably, in most cases, quite a lot of work. > By comparison, "add a bit of SVG-like stuff to your app" (should that be > the agreed way to improve things that for some reason or other are done in > canvas) is often going to be rather less. Which is important in achieving > accessibility. > > Demanding perfection is great if you only care about accessing what is > perfect, but history bears out the fact that people want the stuff that is > actually pretty badly put together, with minimal attention to > construction, but which is actually interesting content. Simplifying the > path for a developer to get it "right", and making it possible to get > incremental benefits, is better than instituting an all-or-nothing > approach which many people would predict will lead to a very large dose of > nothing in places where we could have had "not perfect, but better than > nothing". I've expressed my feelings on this already, that an optional accessibility solution that doesn't offer benefit beyond "makes the app accessible in some aspect" is essentially useless. It's not a matter of being just "good" instead of "perfect", I think it's actually bad - it will only be used by a tiny fraction of web devs voluntarily, and generally only by companies when they're legally required to do so (and even then, only the minimum required to comply with the law, which can easily still end up being useless), but every browser has to support and many authors have to learn about it. The only way to do good accessibility is to sneak it in so that the author accidentally makes things accessible while making it work well for themself or their majority userbase. It's almost impossible to do "very good" or "perfect" accessibility this way, but it's relatively easy to do merely "good" with this strategy if you're sufficiently clever in designing the system, and more importantly, *every* app gains this "good enough" accessibility. I believe that, *after* doing the built-in accessibility, it's reasonable to explore optional solutions so that people who really care can patch their apps up past "good". This is essentially what ARIA does to HTML, which is fine. But starting from the optional API is, imo, almost guaranteed to have bad results, because you don't yet know what's easy and what's hard to do, so you don't know what's worthwhile to spend effort on. ~TJ
Received on Friday, 1 July 2011 18:11:08 UTC