Re: WAI: Threat or Menace?

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