- From: Kynn Bartlett <kynn@idyllmtn.com>
- Date: Tue, 20 Aug 2002 10:54:27 -0700
- To: Svgdeveloper@aol.com, tbray@textuality.com, www-style@w3.org, www-tag@w3.org
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 -- Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com Chief Technologist, Idyll Mountain http://idyllmtn.com Next Book: Teach Yourself CSS in 24 http://cssin24hours.com Kynn on Web Accessibility ->> http://kynn.com/+sitepoint
Received on Tuesday, 20 August 2002 13:54:39 UTC