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

hi Rich

At 1:38 PM 2/2/00, <schwer@us.ibm.com> wrote:
>Mark,
>
>I am not sure what you mean by presentation *style*. Are you suggesting
>syle in the way that we present the issue to ATs?

yes, yes, yes. <smile>


>I didn't think you were suggesting we create another standard. What I
>thought you were doing was suggesting that a user agent could create
>whatever interface they wanted for accessibility and not comply to the DOM
>standard when it pertains to the document.

not <smile>

mark

>
>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 01:27:12 PM
>
>To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
>cc:   Phill Jenkins/Austin/IBM@IBMUS, w3c-wai-ua@w3.org, w3c-wai-pf@w3.org
>Subject:  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 15:06:43 UTC