WAI: Threat or Menace?

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