- From: Daniel Dardailler <danield@w3.org>
- Date: Tue, 10 Jun 1997 17:18:05 +0200
- To: w3c-wai-wg@w3.org
In a recent thread related to ALT content guideline, and in several other discussions (whether D-LINK is better achieved using OBJECT or existing feature, for instance), the issue of timelineness has come up, usually in the form of: Are we working out solutions for the short terms (the existing market), for the longer term? (the market we want to create) or for both ? I'd like to restrict the scope of this discussion to Markup content for now (HTML/XML/CSS evolution and guidelines if you prefer). "For both" looks like the ideal answer, but there are constraints on resources on our side when we write specs and guidelines (it takes more time to come up with a solution for more than one context) and more importantly on resources that we think content providers (to take one example) will be able to spend to understand and comply to our recommendations. Sometimes, of course, short and future solutions can be exclusive of each others. "For the future" is my preferred answer, since it gives us the most liberty to do good design, but it suffers somewhat from a chicken&egg dilemma (who is going to use it and therefore who is going to author using it) and an elitist view. "For the short term" has the advantage that our directives are immediately applicable (on many clients) but may carries a load of legacy drawback that might haunt us for year to come. I think we need to come up with specific cases were the choice is real and try to understand where we have to go (that reminds me the old adage in the Xlib book: "the only thing worse than generalizing from one example is generalizing from no example at all") One case: should we spend our resources supporting dumb screen reader (that do not parse the Markup but act on a final presentation made by some other agents) or should we consider that we're working toward making the most out of Markup-aware-agents and only them ? For example: a guideline exists that advises content providers to provide ascii version of all HTML forms, since dumb screen readera can't make much sense out of them. In this case, we could advocate both, since they are not exclusive, but it is still an issue since it would put the bar higher for accessibility compliance and some people might just drop the ball altogether seeing that it will take too much resources to comply. Maybe the answer lies in setting different accessibility level (back to the rating system). This is really the kind of discussion I'd prefer to have live, face-to-face or on a conference call. I propose that in addition to mail discussion, we organize a phone call to talk about it. If you send me you time constraints for next week, I'll try to book something reasonnable.
Received on Tuesday, 10 June 1997 11:18:09 UTC