Re: RS: Write a proposal for the Techniques Document for loading an assistive technology for direct access to the browsers DOM

hi Al, Harvey, et al:

my comments in MN below:

MN:  first, it took me a while to remember what doc. you both were commenting
on.  The original proposal that Rich and I put together had, as I recall, 4
different mechanisms for AT to work with  or within UA, and from your
discussion below, looks like you are concentrating on the method of
loading into the same address space as the UA, via the Java technology.

>At 12:45 AM 5/30/99 -0400, Harvey Bingham wrote:
>>At 1999-04-12 01:04 PM, Rich Schwerdtfeger wrote:
>>>Access to application specific data across process boundaries can be
costly
>>>in terms of performance. Also, access to the DOM through a specified
>>>accessibility API inhibits the ability for assistive technologies to
access
>>>object model data not yet provided in that API. Therefore, user agents
>should
>>>provide a mechanism to load an assistive technology (AT) into the process
>>>space of the application, as a separate thread, with direct access to the
>>>DOM.
>>
>
>HB::
>
>>Suspicious but unknowing: Isn't this a way for a Trojan horse to get into
>>the user agent? Does ..., as a separate thread, ... give enough protection?
>>I worry that a user agent needs to give arbitrary AT (unknown in advance)
>>access to the UA innards.
>
>AG::
>
>Yes, any extension mechanism has to be engineered for security as though it
>is a potential avenue of attack.  That is just goes with the territory, it
>does not mean we shouldn't seek appropriate extension mechanisms.  The
>state of practice in this regard is that extension mechanisms are supported
>and they have occasional security breakdowns.  All of them.  They are still
>supported.

MN:
actually, if one thinks hard about this, most of what software development
in the AT field has been, falls into the category of being very much like a
trojan horse, a virus, or "something" that alters the way the original
software was intended to run.  Indeed, many hacks have been created over
the years by AT developers to gain access to, and manipulate the information
presented to, the user.  I've often thought, if we could employ any of the
people
who have the time to develop "virus" type software, and get them to use
their talents and system understanding to develop AT, we'd have some really
cool end results.  sorry about the rambling....

actually, whether we load the AT into the same address space as the UA,
or whether we access the DOM from a stub DLL in the same address space,
or whether we access the DOM from a separate process space, each can
present a potential for unwanted results.  however, in practice this is
no different than what has been going on in the AT field for ~20 years.

>
>RS::
>
>>>A technique for accomplishing this would be to store a reference to an
>>>assistive technology in a system registry file or properties file in the
>case
>>>of Java. Registry files are common among many operating system platforms
>>
>
>HB::
>
>>So who controls what can get into the Registry? It is my understanding that
>>a principal cause of Windows crashing is lack of control over what gets into
>
>>the registry, and who can break common information in it to change values
>>to whatever they desire, breaking what other programs need.
>
>AG::
>
>Giving the user the ability to tailor the user interface of all
>applications class-by-class, based on some resource ontology (dictionary of
>types or classes of presentable information) is pro-usability and
>pro-accessibility.
>
>Mark Novak nominated the following resources as good tutorial explanation
>of the Model-View-Controller architectural view which I think we need to
>understand here as well as in designing the details of protocols and formats:
>
><http://java.sun.com/products/jfc/tsc/archive/what_is_arch/swing-arch/swing-
>arch.html>
>
><http://java.sun.com/products/jfc/tsc/archive/plaf_papers_arch/multi_update/
>multi_update.htm>
>
>Be careful to get the whole URL from two text lines in those references.
>
>Yes, people experience problems with the  Windows registry, but the use of
>such a central [to the system or user account] UI-building database is
>still a positive step.  The problem is not the existence and role of the
>Registry, but the logical  model that it implements.  That is what we are
>exploring here.  If the Registry supported seamless AT integration, how
>would it work?

MN:
the registry can be a potential problem, but like other parts of the computer
I think people need to remember to perform regular maintanence.   However,
i'm confused as to why people should read about the model-view-controller
as related to this discussion on loading AT with the UA?



>Microsoft may not respond immediately with a total rewrite of Windows, but
>I suspect that if there is an accessibility advantage to something which
>Java provides, they want to understand it to see if Windows can't provide a
>comparable capability.

MN: from what I can tell, Microsoft already has a mechanism, which was written
about in this doc., called browser helper objects, which load in the same
address space as the UA, in this case IE 4/5, and while running on their own
thread(s) have similar *direct* (in the same process space) access to the
DOM as per the Java technology....I'm looking at some of this very closely as
I type this.........

>RS::
>
>>>In Java 2, the existence of an accessibility.properties causes the system
>>>event queue to check the file for assistive technologies required for
>loading.
>>>If the file contains a property called assistive_technologes, it will load
>>>all registered assistive technologies and start them on there own thread
in
>>>the Java Virtual Machine which is a single process. An example entry for
>>>Java is as follows:
>>
>
>HB::
>
>>I'm dense here:    an  accessibility.properties
>>(is there such? is it a collection?)
>>
>>typo: ...called assistive_technolog_i_es, ...
>>
>
>RS::
>
>>>Once the assistive technology is determined from the registry, any user
>agent
>>>on the given operating system can now determine if an assistive technology
>>>needs to be loaded with their application and load it.
>>
>
>HB::
>
>>Does this preclude more than one AT to be available? Are there times where
>>more than one are required: such as both braille and speech output?, or
>>voice command and special keyboard?
>
>AG::
>
>If I read Rich right, the system loads "all ATs registered" as needed for
>the class of the object being accessed.  That sounds as though multiple ATs
>(such as concurrent disposition to both Braille and speech) can be supported.
>
>If multiple ATs are to be loaded, they have to be designed and tested for
>compatibility; they can't make contradictory assumptions.  This is a
>necessary part of the extension mechanism (discipline, as used) that is
>mostly separate from the
>real-time transaction where an object is opened and ATs appropriate to its
>class are linked in as a result.
>
>Actually, both your concerns point to a single place.  The time to check
>the compatibility status of a pair of ATs is when registering them both to
>the same class of resource object.
>
>Al

MN:  while one would love to have all pieces of AT software be compatible, I
don't realistically think we can expect that any more than we can expect
2 different commercial software packages to co-exist.  Standards help, esp.
when developers follow them, and this is further assisted by market
pressures.  The key here is if the user requires one or more pieces of
software/hardware, that the "system" can accomadate the user.



>>
>>>Rich Schwerdtfeger
>>>Lead Architect, IBM Special Needs Systems
>>>EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
>>>
>>>"Two roads diverged in a wood, and I -
>>>I took the one less traveled by, and that has made all the difference.",
>>>Frost
>>>
>>What a joy to find that saying on a rock in the woods on a farm that Frost
>>once had [Now a Vermont state park, I believe], and having the choice he
>>probably had in mind.
>>
>>Regards/Harvey Bingham
>>
>
>

Received on Tuesday, 1 June 1999 11:09:20 UTC