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

hi Rich

I'm not suggesting we don't use DOM, and I'm not suggesting
we create yet other standard.  I'm suggesting that presentation
*style* can make a huge difference in whether or not someone
"buys-in" to an idea.

regards

mark

At 12:33 PM 2/2/00, <schwer@us.ibm.com> wrote:
>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 14:24:21 UTC