- From: Charles McCathieNevile <charles@w3.org>
- Date: Fri, 21 Nov 2003 22:01:07 -0500 (EST)
- To: Joe Clark <joeclark@joeclark.org>
- Cc: WAI-GL <w3c-wai-gl@w3.org>
There is a tension here that has resisted simple attempts to resolve it. I will begin with an example of the problem, and follow with some thoughts on what a solution might look like (since I don't have a clear and polished answer). SVG, a moderately new technology (the first implementations are only about 5 years old, and the finished recommendation is only a couple of years old), has been described by one accessibility expert as "vapourware" - i.e. not suitable for making content available. On the other hand, it has the ability to encode beautiful graphics, nice fonts with cool artistic effects, or what I would think of as hideously unclear pictures which obfuscate the idea they convey in a swirling miasma of animation effects and groovy filters, in a way that allows for conformant user agents to provide the clear accessible version of the information that the author included. (The SVG specification has formal accessibility requirements in its conformance section, and there is information around on ways to make it happen). Should authors avoid SVG? Should we "de-invent" it, and stick with the old raster formats that don't provide these accessibility features? Should we require people to work with the real-world mess of broken browsers? South America has a lot of people using email-based browsers, or windows 95 or 98 with a version of Internet Explorer 5, or Netscape 4? Or should we say "while there are only 7 people in the world with a working implementation of the format exampleML, it is very much better for accessibility than what is commonly used, so feel free to use it and claim your content is accessible"? It seems to me valuable to work with things that are available. People developing for a new technology may not be creating content that is generally accessible, but content that will be more accesible in the (near?) future. People who ignore new features that are developed, and which don't have any ill effect when not supported, are in my opinion slowing the development of accessibility. The difficulty is finding a reasonable definition of when it is reasonable to use a new technology that is not backwards compatible. Or saying it another way, how much implementation in browsers, and how much do those browsers need to be used in the real world, is required for something to be useful? I don't think that "specified in a W3C recommendation" is sufficient to meet the requirements. Nor does it make sense to me that "works in Netscape 3" is a requirement. So I think a working approach would specify how to decide what level of implementation is necessary. Perhaps none - if the working group decides it doesn't matter whether tools are available to actual humans. Examples that have been proposed include whether something is available for two languages, or two operating systems, or for free, etc. Similarly, it should describe some way of determining what technology does not need to be supported (assuming the working group believes there is some technology in this category). So Joe is right that it is important to encourage development of newer and better technology, but I think it is not necessarily a good idea to assume that something is accessible just because it could be if people had the right software. I suspect finding a reasonable balance is going to be difficult - and "ask an expert" is probably not sufficiently specified to put in the guidelines... cheers Chaals On Thu, 20 Nov 2003, Joe Clark wrote: >> Moving on to checkpoint 4.3 - >> Assure that technologies required to render the content are listed and >> widely available -- OR -- Use widely available technologies to render >> content, and list the technologies that are required [level 2 guideline] > >A terrible idea. Some ancient HTML techniques, like <a rel> or <a type>, >are virtually unsupported. And now we're going to limit what future >technologies people can use? > >Why not just de-invent the Web? [etc]
Received on Friday, 21 November 2003 22:01:32 UTC