- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Mon, 31 May 2004 22:53:06 +0100 (BST)
- To: w3c-wai-ig@w3.org
> orthogonal to disability. These things are out of our scope, and You are using the narrow definition of accessibility. Several people here (and I suspect the founders of the web - have a look at TBL's original proposal for the web) have a broader definition of accessibility, which means accessibilty to the whole of humanity, even if they are constrained by finance, bandwidth, security policies, software that they cannot control, etc. The narrower definition tends to be easier to sell to businessmen, as they can identify themselves and their family as potentially becoming the people needing that accessibilty. > techniques for WCAG 2. The end product will consist of techniques for > keeping JavaScript from causing accessibility problems, and producing I assume you mean document and browser object models, possibly using EcmaScript. JavaScript is, by tight definition, more or less EcmaScript and by broad definition also adds Netscape's proprietary, and obsolete, object model. > how we got into the mess we're in, and our ideas on a way out. Other The main reason people have got into a mess is because they have been using tools developed from HTML, an information communication language intended for broad definition accessibility, rather than using its contemporaries, and predecessors, designed with advertising and other commercial requirements in mind (PDF and various animated presentation tools), but are trying to do the job of the latter. You mention compound documents. In practice many internet accessed sites[1] as a whole are one compound document, which very much goes against the concept of the web as being made of lots of individually addressible pages interlinked in complex ways. Using the proper tools could tend to reduce accessibilty, as those tools were designed to meet requirements that didn't include accessibilty. However, one of the contributions of HTML has been that those tools now do cover accessibility. In fact, I would say that tagged PDF provides a better compromise between commercial requirements and accessibility, because it starts from the physical form, but then adds fully detailed structural information, whereas the HTML/CSS route starts from the structural form and then just hints at the physical form. Moreover, trying to do things in HTML for which it was not designed, means that most "HTML" doesn't use its accessibilty features. That tagged PDF is not used for sites is, interestingly, a broad definition accessibility issue. It's done because it is assumed that users won't all have installed the reader. (It's also, I think, because designers don't really understand what PDF is (as well as not understanding what HTML is - which you can tell by the near universal use of invalid HTML).) > papers[3], at least all of those that I've read, say the same thing: > declarative code cancels out scripting, and we need declarative > languages to build these user interfaces we've been building all these Certainly some things that are currently done using object model manipulation should be done declaritively. However, one of the reasons that people use scripting is to re-instate features that were deliberately not provided declaritively. Possibly the most common example of this is using scripting to force new windows - which is also the most common reason for sites becoming inaccessible without scripting. > We have to take this on. There is no alternative. Script is here to > stay, and if the WCAG document fails to recognize it, it will fail to > be adopted. It's already a problem that accessibility conflicts with perceived [2] commercial requirements and is not adopted, except when forced by law. That's true in a far wider area than the web. People need the laws because the market favours companies that don't spend money on accessibility, so all companies have to forced to provide accessibility, to create a level playing field. As I'm sure that you will still want to go ahead with supporting commercial wants, please make sure that you analyse things in terms of the fundamental requirements, like branding, pre-selection of high value customers, intellectual property protection, lock-in to the site, creation of emotional and other associations that cannot be justified by the nature of the product, etc. rather than in terms of techniques, like popups, etc., even though people will not want the markup to make many of these reasons explicit, so will still want to markup in terms of techniques. [1] I prefer "internet accessed site" to "web sites" as typical sites do not have the characteristics that would make them web sites, namely inward links at all levels and extensive links to many other web sites. [2] However, although not based on a scientific study, it is surprising how large a proportion of web users not in the web site industry, find the flashy features of web sites an obstacle to use. These are the sorts of site that designers believe they need to create and which create the demand for "browsers" being application program platforms, rather than document browsers - also, there is little money in document viewers.
Received on Tuesday, 1 June 2004 02:17:41 UTC