- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Tue, 20 Aug 2002 11:15:12 -0700
- To: Kynn Bartlett <kynn@idyllmtn.com>, Svgdeveloper@aol.com, tbray@textuality.com, www-style@w3.org, www-tag@w3.org
Kynn, I think you come up with some very good points here, though I'd add another possibility to the list, albeit one that is a good ways out: Create browsers that are capable of taking markup language that tells the browser how to upgrade itself to display particular kinds of content. Most browsers currently use a plug-in architecture which does much the same thing, but the problem there is that there is no standard for plug-ins (primarily due to the fact that MS has taken a different route from the Java-based browsers). Suppose that you had a browser that was self configuring in this regard - and could intelligently take the configureML and use it to build a viewer/editor that worked within the constraints of the system - a low mem back and white device would take the configureML and create a Tiny SVG implementation, whereas the same configureML would tell a robust browser to create a Full SVG implementation. By keeping the logic in an ML, different systems could perform the same types of updates in different ways. In essence this ML would be analogous to a makefile, or javac acting on a *.java file. Oh well. -- Kurt Cagle On Tuesday 20 August 2002 10:54 am, Kynn Bartlett wrote: u> At 3:52 AM -0400 8/20/02, Svgdeveloper@aol.com wrote: > >2. The Web Accessibility Initiative, as currently formulated, may be > >potentially harmful to the future development of the Web > > I don't see this at all. Rather, the Web Accessibility Initiative is > having to deal with very real problems and is attempting to come to a > solution for those. > > In this particular case, the question is "how do you make content in an > arbitrary XML format accessible to an audience with disabilities?" In > this context, "arbitrary XML" means "an XML language whose meaning is > clear to the author, but the user agent only has the syntax to go on." > > Some of the possible solutions include: > > 1. Recommending that users should never be sent arbitrary XML, and > should instead receive content in a mutually agreed-upon format > which the user agent can comprehend. > > 1a. An example of a language which is designed for this purpose > is XHTML, because the user agents have foreknowledge of what > each XML element in XHTML is "supposed to represent." > > 1b. Another example is SVG, which likewise comes pre-defined. > A problem exists, though, when the user may not have a > browser which can render SVG effectively. While it is an > easy answer to handwave that this is a browser problem, > and the user should simply employ a better user agent, it > is also true that most new development of software and > hardware is NOT concentrated in the development of > assistive technology. If anything is "holding back the > future development of the Web," it is those developers of > software who do not build AT-compatible software. > > 1c. Another example of a language is XSL-FO, which defines > a final format for displaying a document. While there > are indeed some "hints" embedded in an XSL-FO document > which can be used to infer certain types of meaning, it > is inaccurate to say that all information necessary for > understanding and using a document via a non-visual > method can be accurately determined from the visual > rendition. > > 2. Another idea might be to require that XML documents be sent > with an appropriate style sheet if the XML is intended for > display to users (and not merely computer-to-computer > communication). > > 2a. This allows for browsers which don't understand the > arbitrary XML markup to attempt to display the document. > The reason that XHTML would be favored as a transmission > language is that Web browsers generally have a default > (explicit or implicit) style sheet for rendering each > element in the XHTML tagset. Arbitrary XML lacks such a > default style sheet, so a requirement that arbitrary > XML _must_ be sent with a style sheet provides for this > problem. > > 2b. Furthermore, it probably makes sense that _all_ XML, > even non-arbitrary documents, should be sent with a > a default style sheet. If XML browsers are in widespread > use, then it may happen that there actually is no default > XHTML style sheet available; the XML browser might not > speak XHTML in the slightest. Thus, all XML documents > should be provided with a default style sheet for proper > rendering by XML user agents. > > 2c. Most style sheets for XML or XHTML documents only describe > visual formatting; however, this is not sufficient for the > needs of non-visual users in many cases. Therefore, > aural CSS styles (or the equivalent) should be provided > for all XML documents. > > 3. Here's yet another idea -- develop some sort of meta-language > which can be used to assign meaning to particular elements in > arbitrary XML, thereby telling the user agent what the language > means. > > 3a. For example, tell the user agent that <headline> is a > type of heading, and should be displayed however the > browser displays headings. > > 3b. This would be useful in bridging one of the key gaps in > XML-CSS right now -- an inability to specify that "this > tag should be presented like some other tag you may already > know." > > 3c. However, this approach also serves to erase one of the key > features of XML by adding on a set of pre-defined meanings > to certain tags or attributes. This may not be a bad thing, > necessarily, as we have already seen many new additions to > the XML pantheon which define core functionality via > pre-defined elements and attributes -- XLink, for example. > > 3d. Such an approach may be unweildy in that it may require > defining either a whole lot of individual "meaning objects", > and the time may be spent better served by developing XHTML > (2.0 or beyond) into an improved language for human-read > content communication. > > 4. XML elements often include human-readable tag names, such as > <headline>, which could be used to infer meaning. > > 4a. While this does not help very much with making the > content computer-readable, an intelligent user agent could > provide the user with direct access to tag names, perhaps > via some sort of tree or query interface. At the very > least, the user agent could offer to prepend each element's > content with the tag name: > > headline: Arabs Fear Bush's q: Mad Quest for War > > Or even: > > headline: Arabs Fear Bush's q: Mad Quest for War end-q > end-headline > > 4b. In such a scenario, authors would be required to ensure > that their tags are indeed human readable and make sense > to an audience which is unfamiliar with the specific > arbitrary XML being used. For example, the use of <q> above > is very ambiguous, and may cause confusion; instead, the tag > name <quote> should be used. This implies some sort of > guidelines for tag naming. > > 4c. In addition, the specific natural language being used for the > tag names should be identified, if it does not match the > xml:lang value for the document. In most cases this will > not be a problem, but the identification is necessary for > proper screenreader use. > > 4b. Namespaces. This is a problem, because you will have to > somehow present namespaces to a non-technical user audience > once you give them direct access to try to understand the > XML. On one site, <author> may mean the author of a page, > and on another, <author> may mean the author of a book. From > a technical XML standpoint, this is easy to explain by > simply using namespaces; however, requiring users to understand > namespaces and the differences between specific tagsets is > likely beyond reasonable expectations. Consider that an > arbitrary XML document may contain several tags with the > same name but which are quite obviously different elements > based on namesapces; the fact they have the same name is > purely a coincidence. How do you present this to the > non-technical, disabled user if you presume that tag names > will automatically convey meaning? > > 5. Or I guess we could just ignore the problem and hope that someone > creates magic software which solves all difficulties for people > with disabilities. > > --Kynn
Received on Tuesday, 20 August 2002 14:18:58 UTC