W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Accessibility and design principles in action Re: Use Cases for The <canvas> Element

From: Charles McCathieNevile <chaals@opera.com>
Date: Wed, 01 Aug 2007 13:50:20 +0200
To: "public-html WG" <public-html@w3.org>
Message-ID: <op.twdpt6pjwxe0ny@widsith.local>

On Tue, 31 Jul 2007 03:22:37 +0200, Karl Dubost <karl@w3.org> wrote:

> Le 31 juil. 2007 à 07:01, Maciej Stachowiak a écrit :

>> My personal conclusion is that both retained-mode and immediate-mode  
>> graphics are useful. I'd guess that browser implementors largely agree,  
>> since Opera, Firefox and Safari* are all supporting both SVG and Canvas.
> Yes I guess that both things are useful. There are two issues which  
> Robert Burns started to address.
> ...
> * authoring (declarative versus programmatic)

This thread shows a couple of things. One is that user agent developers do  
have a lot of power over what HTML is. Why the shock? On the web, people  
author around IE's old box model. They optimise sites for Nintendo Wii,  
iPhone, or Opera mini. They deal with strange behaviour in Netscape 4. So  
whatever HTML *should* be, what it is includes a huge amount of  
recognition (in terms of code volume) that user agents are the bedrock  
requirement for most "normal web developers" (note that this doesn't apply  
everywhere, but I don't think that matters).

There are, as Maciej pointed out, use cases for both canvas and SVG - and  
three browsers are introducing the two in parallel. (I won't go on about  
the use cases - I think both technologies have proven support. If you want  
to see more canvas, have a look at the most popular Opera widgets. If you  
want to see more SVG, have a look for things that try to be accessible,  
and think about how they can do it).

In other words, including canvas is really about paving emergent cowpaths  
- ones that were so clear to the people framing HTML 5 in the WHAT-WG that  
it is not easy to find out now how this came about. It seems perfectly  
justified to me (although I have grave concerns with the way authors will  
provide accessibility, and believe that the current pattern were most  
canvas authors just don't bother will continue :( ).

It also highlights a disconnect in the group about how to handle  
accessibility. (The original point of Lachlan starting this thread was to  
show we have effectively treated canvas the same way as, for example, the  
headers attribute, so I claim this is on topic). There are a lot of  
accessibility features in HTML 4 - and most of them are used in a minority  
of cases, often badly or wrongly.

I think the disconnect comes from the way accessibility works in practice.  
People with disabilities often cannot do some things that others take for  
granted. Simple stuff, like shopping at your favourite site, listening to  
music with your favourite music player, reading the newspaper, voting,  
paying taxes, applying for a job, using a browser. In some cases, most  
things do not work, in others a few. When your life is circumscribed by  
such problems, everything that *does* work is valuable. And the web has,  
in a number of cases, opened a huge range of new options to people, since  
one shopping site that gives access makes up for any number of competitors  
that don't (and as any free-market zealot knows, two such sites that are  
run independently will improve things even more - even in a situation  
where another ten thousand sites are not available).

So "design for universal access" really has two aspects. One, quite  
correctly understood by nearly everyone, I think (although naturally with  
varying interpretation in a given case) is to make HTML 5 support better  
accessibility in the future.

The other, which leads to so many problems, is not to rip up the few  
carefully laid flagstones that have often at great expense been put down  
on the boggiest patches of common cowpaths. Don't, for example, kill off  
something that is only used by the handful of people who will do anything  
to be accessible, since there are people who really really need it. Even  
if it only works on a handful of UK government sites, in a couple of  
browser/AT combinations, and therefore has an audience of about 100,000*,  
something that does provide accessibility and doesn't actually seriously  
break the web is generally worth keeping even where 80% of the usage fails  
to achieve the goal.

This is not the same as saying "don't fix it". It is just saying "don't  
break it while we are experimenting with a new answer", since you cannot  
guarantee that the fix will work, and destroying a handful of things  
people rely on in exchange for some new ideals, however much we believe  
that they will lead to improvement in overall accessibility, isn't a very  
helpful thing to do to people.



* A conservative guess at how much a given feature is usually worth today  
based on the fact that the UK is the best at getting these things deployed  
sensibly, and .5% of the population might be expected to benefit from  
anything I thought of in about 3 minutes reflection. Research from  
Forrester done for Microsoft claims that overall accessibility  
requirements assist about 2/3 of *all* Microsoft's users, so we are not  
necesasrily talking *overall* about small concerns).

   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com    Catch up: Speed Dial   http://opera.com
Received on Wednesday, 1 August 2007 11:50:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC