Re: Tentative meeting on the DOM with AT vendors for the User Agent Guidelines

I would like to be much stronger with how the DOM is required for
accessibility. In terms of the chrome, I believe that an User Agent can
make their application accessible by using the native chrome accessibility
support (MSAA/Java). For the actual Document representation I believe the
the application writer should be required to implement the DOM. Here is
why:

- It is a W3C standard and the W3C is using this as a conduit for providing
access to the document.
- From an AT perspective, standards are needed. Otherwise you end up with
tons of proprietary standards that can be proliferated on a per application
basis.

The problem with introducing yet another non-standard interface is that the
user will have to wait until the assistive technology is capable and
willing to support the interface. It also makes writing any UA techniques
document near impossible.

Rich


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


menovak@facstaff.wisc.edu (mark novak) on 02/02/2000 11:05:00 AM

To:   Phill Jenkins/Austin/IBM@IBMUS, w3c-wai-ua@w3.org, w3c-wai-pf@w3.org
cc:
Subject:  Re: Tentative meeting on the DOM with AT vendors for the User
      Agent Guidelines




hi Phil

At 2:56 PM 2/1/00, pjenkins@us.ibm.com wrote:

>> i'd advocate that DOM is just another tool/method, and if company A
>> chooses to use DOM, or an  OSM, or some other idea, that is company A's
>> decision.  i don't support the concept that *all* companies have to
>> use DOM .  I understand the advantages and dis-advantages, just
concerned
>> about any "tone" we present to the AT community.
>
>We need to distinguish between "browser company" and "AT company".

when you say "we", I'm not sure who you are referring to.  I think
you mean the UA group, and if correct, I agree that the UA guidelines/group
needs
to keep in mind the differing requirements of a UA  versus a AT developer.

>I feel
>the "browser company" meets its part of the accessibility contract when it
>provides information to the AT via the DOM.

I would also agree with this, but I wouldn't say that is the "only" way
a UA might be able to meet this requirement.  The UA should expose
all of its content, and using DOM would seem a "logical" method to do
so.


>If the AT doesn't utilize the
>DOM, and that is the only [or best] method that "browser" provides, it is
>still the AT's responsibility to provide the work around or implement the
>DOM.

Again, I would agree, the AT (if they want to stay in business) will have
to provide access to the information in the UA.  "If" using DOM is found
to be the best method to do so, and the AT doesn't use DOM, then they may
or may not meet their responsibility. The UA group should provide examples,
source code, etc., to encourage DOM use.   But that is a decision best left
to
the AT developer, not the UA group.


>We can't go forward with accessible technology by always shackling
>ourselves with legacy solutions.  The solution needs to be technically
>accessible.  We can't continue to burden developers and authors with
>redundant solutions either.  Redundant solutions cost TWICE as much.  Side
>issues, such as whether some or when all AT's support it and whether the
>user has the time/money/space/patience to upgrade both the browser and the
>AT, should also be separated.


I'm not suggesting any of this...  I'm simply cautioning the UA group that
"how" we present using DOM or any other technology to the AT community
is just as important as the technology itself.

mark

Received on Wednesday, 2 February 2000 13:50:28 UTC