We're discussing a choice in making things accessible between better
authoring and better rendering. But there's a third way.
The problem of making even rich interfaces accessible would be somewhat
reduced if we had an additional abstraction layer in place. My suggestion
would be an intermediate XML language that has a real semantic foundation.
A primary design goal for XML as a framework for defining languages was to
establish a way to state the meaning of what is being communicated. Then
based on the meaning, renderings can be constructed that are suitable for
the context and the audience.
Microformats are a bottom-up approach to designing XML sublanguages to
represent particular objects. John Allsop has advocated looking at
microformats that capture standard meaningful constructs in page design.
In documentation and training world, however, there are already three
reasonably mature publicly-available standards-based XML-based languages
for representing information: Docbook, OpenDoc (if I have the name right),
If we looked for a way to build a back-end XML dialect that would smoothly
integrate what we consider to be the major ingredients of software-based
user experiences, that effort might yield a real resolution to the
accessibility problem. In environments based on semantic markup, the
information would be available that is required to render an interface in
various subsets of the conventional sensory set. It would be best if the
effort were in a standardization forum such as W3C or OASIS so that the
level of advancement of the language can be tracked and objectively judged.
It isn't good enough to cite XML encodings of complex notions that are
native to other languages. The idea is to build the notions as XML
constructs, and obtain any complex markup that might be needed from the XML
At 03:19 PM 10/5/2007, Petteri Hiisilä wrote:
>Joseph Selbie kirjoitti 5.10.2007 kello 20:40: > > > I'll make it even more complicated: it isn't just a matter of > > whether the > > screen reader (say Jaws) can read your code. The question will > > become can > > the reader effectively make every feature and function usable by > > the user. > >And even more complicated: let's assume that the code works perfectly >and you have perfect understanding between the screen reader and >yourself. Effectively: you'd have someone who you know and someone >who knows you handling the mouse and the keyboard. You know, like a >considerate human. Now, how would you navigate the site and how >effective would that be? I guess that would set the bar for screen >reader usability. > >But that wouldn't be the high mark. The mind's eye can see with >touch. It would be faster to "see" the pixels if there was a perfect >touchscreen that can display edges, maybe even grades of gray as >little bumps - and such screen would respond to taps and gestures. >Blindsight! > >Downgrading those to something that can actually be implemented is >hard if not impossible during our careers. I'm all in with making >technology accessible, and I like standards, but suing companies for >not reaching such an arbitrary bar is questionable. > >Best, >Petteri > >-- > Petteri Hiisilä > Senior Interaction Designer > iXDesign / +358505050123 / >petteri.hiisila at ixdesign.fi > > "Simple is better than complex. > Complex is better than complicated." > - Tim Peters > > >________________________________________________________________ >Welcome to the Interaction Design Association (IxDA)! >To post to this list ....... discuss at ixda.org >List Guidelines ............ http://beta.ixda.org/guidelines >List Help .................. http://beta.ixda.org/help >Unsubscribe ................ http://beta.ixda.org/unsubscribe >Questions .................. list at ixda.org >Home ....................... http://beta.ixda.org