[Accessibility] Sec 2b Draft -- For today's call
janina at rednote.net
Fri Sep 5 06:55:52 PDT 2003
We missed you on the call, but are glad to untangle remaining issues on
the list. I'll be posting an item by item breakdown shortly in order,
hopefully, to keep our subject threads disentangled.
As to structured navigation ...
I recognize that AT-SPI does this, though I'm not sure that it does as
much of it as I have in mind. I'm aware, for example, that AT-SPI knows
about groupings--parent/child relationships, etc. But is there a
mechanism to classify a parallel structure that span's hierarchical
structures? I don't know that one would need this in desktop/software
interfaces, but this is how we handled pages (as with print book page
numbers) in DAISY 3.0. Or, how about free flating relationships such as
footnotes and sidebars? Or, how about tracking/syncing multiple representations of content, e.g. an audio and XML text version as with today's DAISY content--or the two Hollywood versions of Henry V plus the Shakespearean script?
Does this take us out of scope? Perhaps. But, I thought we had decided
it didn't as long as this was a service interface that user
agents/display technologies could take advantage of.
Also, we have this way out in year 5. By then I expect we'll have done
something about multimodal interfaces, possibly including audio only
interfaces such as the telephone which we don't yet directly address but
certainly has its compliment of well-known accessibility issues for
deaf, hard of hearing, and mobility impaired constituencies. A pro pos
multimodal, I'm expecting that we'll have XML technology addressing much
of this via the W3C by then, and probably from other sources as well. In
the W3C this isn't just a topic for accessibility, of course, it's also
an interest of those segments that want to devise strategies to allow a
single backend data/content storehouse to serve all kinds of
devices--the Device Independence WG.
In my mind it is certainly possible that one way to address all of this
is with a 2.0, or a 3.0 of AT-SPI. I am not even sure but that AT-SPI
gave me the notion that there is a common layer here that could be
assisted by a capable, DOM aware, service API. Of course, I don't have
my hands down in the code like you do, so I may well be over-reaching.
Is this helpful? Does it suggest changing the description? Or are you
still thinking the item itself needs to be dropped? And, if we drop it,
how do we address the kinds of things I mention above?
P)S: I would agree that naming LD was a rather lazy place holder.
Clearly the accessibility benefit of the kind of service that I've
vaguely identified is far more reaching, if it's buildable.
Bill Haneman writes:
> From: Bill Haneman <bill.haneman at sun.com>
> Hi all, sorry I could not attend yesterday.
> I have more comments later, but for the moment I will make one...
> Janina wrote, about 'Structured Navigation':
> > 12.) Structured Navigation
> > It should be possible for users to navigate the user desktop, applications,
> and individual documents in a straight-forward and consistant manner,
> > especially where a hierarchical organization is available. This project
> will develop an API to expose structures to user agents.
> I guess I still do not understand what this item is about - or, more
> precisely, how it differs from AT-SPI. AT-SPI already exposes the
> desktop, applications, and document content in a hierarchical manner via
> uniform APIs, and we try to make the implementation of those APIs as
> uniform as practical across these cases.
> If what we are looking for however is broader or deeper in scope; e.g. a
> universal user-interface structuring API or description language on the
> lines of UIML, then I don't it's appropriate to attempt to create or
> require such a standard since, to date, noone has achieved much success
> in this area. Similarly I do not think we can be so aggressive about
> forcing existing interfaces to be as consistent as might be implied by
> the paragraph below referring to learning disabilities. Modified
> screenreader technology, highlighting for dyslexia, etc. is achievable
> and proven, but going beyond that is out of scope for us I believe.
> - Bill
> > Persons who have various learning disabilities will particularly benefit from this API because developers will be able to create taylored, even
> > individualized interfaces that present information, available applications, documents, and media presentations that can be started, stopped, and used in
> > a consistant manner appropriate to the individual user.
> > 13.) Voice I/O
> > --
> > Janina Sajka, Director
> > Technology Research and Development
> > Governmental Relations Group
> > American Foundation for the Blind (AFB)
> > Email: janina at afb.net Phone: (202) 408-8175
> > _______________________________________________
> > Accessibility mailing list
> > Accessibility at freestandards.org
> > http://www.freestandards.org/cgi-bin/mailman/listinfo/accessibility
Janina Sajka, Director
Technology Research and Development
Governmental Relations Group
American Foundation for the Blind (AFB)
Email: janina at afb.net Phone: (202) 408-8175
More information about the Accessibility