[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: XFO Mapping...


Subject: Re: XFO Mapping...
From: Guy_Murphy@xxxxxxxxxx
Date: Wed, 5 May 1999 10:40:07 +0100

Hi Paul.

What I'm trying to get together in my head (and I confess the idea is
nacent) is a mechanism to allow the second option you outline to be
undertaken by the stylesheet author, so that they can define the mappings
that allow graceful degradation.

As for your point about this being the role of the standardisers I think we
diverge at this point although I admit to reservations to my own
divergence. My own bias is that of a Web designer, so I am aware that I
might be taking the position of a control freak on this matter, and
ultimately you might be right.

Your example of a dialog box sits in my mind in a gray area, an example I
would prefer to use is a menu. I don't believe that a menu can degrade
gracefully into aural media. All the visual queues that are present to
inform the user that it is a menu are absent, and I'm worried that the
listener might just be presented with "Home", "Products", "Contact"....
with no context being conveyed to them. A menu is a visual navigation
construct, what I would like to present is an aural navigation construct
that clearly conveys that context, and outlines options to the listeners
and instruction on how to vocalise actuation.

As to XFO not being up to the task of degradation....

If we provide a mapping mechanism, then we provide an oppertunity for the
author to do the right thing, while trying to reduce the effort to do so,
and while not obstructing those who *really* wish to do the right thing and
style specificaly for listensers, braille or whatever.

Also if we persude what I would like to see, and that is XFO for basic
textual layout, and a seperate namespace for GUI presentational objects
which *could* degrade gracefuly into aural constructs then I think we'd be
a significant step ahead of a "HTML on steroids", we get all the
flexibility and extensibility while being able to cater for degradation to
other media.

I do however appreciate that I am biased by what I would like to do in
terms of Web design, so I should limit my comments to the context of what I
want to work with, rather than any claim that this is the "right thing".
::shrug:: I just want to build highly interactive easily accessible Web
application in the most scalable, robust fashion possible.

I do know that if we had a set of aural presentation objects, I could
impliment them in IE5 now easily rather than some point in the future.
While I may well be doable it's beyond my ken to parse a document and infer
aural presentation in a useful fashion.

And I do genuinely keep you position under consideration as you might well
be right.

Cheers

     Guy.








xsl-list@xxxxxxxxxxxxxxxx on 05/04/99 05:00:25 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: XFO Mapping...




[SNIP]
When an OS designer goes about making their OS accessible, they take two
separate paths:
 * they invent entirely new APIs (e.g. speech plugin APIs) for those
developers willing to go the extra mile to make their applications
accessible.
 * they reorganize their existing APIs so that accessibility can happen to
some extent "automatically." E.g. they provide non-visual ways of
accessing menus, they provide ways of increasing the system font globally
and so forth.
I think that those two strategies are equally important.
You seem intent on deprecating the second route. According to your logic,
dialog boxes designed for sighted people are not optimized for blind
people and thus should not be available to them. Do you think that blind
people would prefer to depend on the goodwill of application designers to
completely rethink their interfaces in terms of sound or do you expect
that they would appreciate whatever features Microsoft provides to make
them accessible "by default"?
--
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco
The first three Noble Truths of Python:
  All that is not Python is suffering.
  The origin of suffering lies in the use of not-Python.
  The cessation of suffering can be achieved by not using not-Python.
http://www.pauahtun.org/4nobletruthsofpython.html

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list






 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread