- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Thu, 3 Jun 2004 09:24:48 +0100 (BST)
- To: w3c-wai-ig@w3.org
> Which is precisely what I, and I believe Matt, are saying. I'm seeing > no difference between a doc or an interface that sits on a URI. As such > we should be gearing toward accessibility recommendations that provide > guidance for both paradigms. They need different rules. For a start, the application is a user agent not the document itself, but, more generally, the rules for applications are the sorts of rules that would apply to a .NET thick client, Visual Basic, Sun Java etc. I can download the SETI@Home client using a web browser, but I don't think that anyone has claimed that WCAG applies to that. The fundamental difference between a document and an application is that a document makes all the information accessible to appropriate tools, whereas an application only gives out what the application writer wants to give out and only in the ways they chose to give it out. Except to the extent that you can sometimes see inside an application's code, to embedded data, documents can be indexed by search engines, but an application as the only access to a document does not support search engines. The confusion between documents and applications is partly because authors assume that they will be directly interacting with a human (and normally assume that they will be doing so on a high resolution raster graphics device), whereas the benefit of something like HTML is that it can pre-processed by a machine. Note. My impression is that Microsoft's main current interest with web browsers as application platforms is for intranets, where there is some control over the user agents used. Even then, one of the main reasons for businesses using client side scripts, rather than VB is that it makes deployment of the code easy (most users don't realise that they are having a program library effectively installed when a .js file is linked into a page). One of the primary reasons that deployment has been a problem in the past is that two PCs rarely have the same configuration. (Microsoft are clearly aware of that from the ways in which they promote .NET as a partial solution.) In an intranet environment, some accessibilty rules can be relaxed, because you know your current user base, although you still need to be able to adapt to changes in that user base. My impression is that many businesses use "web browsers" mainly as a GUI library that comes pre-installed, and which students have self trained on, rather than as a document viewer. HTML is actually a poor platform for this, but it had the advantage that initial mockups could be done simply and the programming department could be left with the problems of making it work in the fully fledged form, after the user interfaces had been agreed. For most purposes, businesses using it in that way treat the actual, branded, browser product as providing the platform, not an abstract specification. Most intranet web applications I've seen attempt to acheive a fixed layout, so lose most of the accessibilty advantages that might have resulted from using HTML over VB or .NET. They fall to pieces if people try to override font sizes.
Received on Thursday, 3 June 2004 06:17:28 UTC