Thread Subject: Re: "closed software"

From: Gregg Vanderheiden
Date: Thu, Feb 01 2007 9:30 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Peter Korn: "Re: "closed software""
• Previous message in thread: David Poehlman: "Re: "closed software""
• Messages sorted by: Author | Thread | Date

A couple of thoughts

- Would we need to establish that the API provided enough info and control?
- What if there are multiple?
- are these 'standard' APIs or do companies get to change them?
- Does IT or AT get to define the API?


I love the idea of APIs. Just don't know the answers


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Thursday, February 01, 2007 8:07 AM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC General Interface Accessibility Subcommittee';
> 'TEITAC Subpart A Subcommittee'
> Subject: Re: [teitac-subparta] [teitac-websoftware]
> [teitac-general][teitac-closed]"closed software"
>
> Hi Peter et al, Can we take the approach here that any at
> built or modified after some future date must support the
> api? Can we enccourage establishment of a working
> relationship between and among the various stake holders to
> move this forward? have we already done so?
>
> Thanks!
>
> On Feb 1, 2007, at 12:29 AM, Peter Korn wrote:
>
> Hi Randy,
>
> Sorry for the delay in replying; I'm catching up on old e-mail...
>
> > /Did /we establish that working with all AT is too much?
> >
> > Peter - Do you mean being compatible with at least one type
> of AT for
> > a specific access method (eg. screen readers) should be good enough?
> > Because that's very different than saying "working with all
> AT is too
> > much". To me, the latter sounds like it could include one type of
> > disabilities but exclude others.
> >
> > As Gregg points out, this is a slippery slope...
>
> I'm suggesting that there are boundaries, with what is reasonable
> somewhere in the middle. Each application inventing its own API which
> provides all the "necessary" information (whatever we define
> that to be)
> is untenable. AT cannot keep up with that; we're left in perhaps a
> marginally better situation than we are in now - where AT has to
> potentially special case every app out there. So I suggest
> that this is
> untenable. [Mind you, some might say that under today's 508 language
> this is perfectly acceptable - the information AT needs is exposed so
> the app is done - same equally untenable situation].
>
> At the same time, we have in a product like Slimware WindowsBridge an
> example of an AT that is no longer supported, though some may
> still use
> it. Requiring that all AT, including something like WindowsBridge,
> support a particular API before it can be used by apps, is likewise
> untenable.
>
> Trying to narrow these boundaries somewhat toward eachother, we have
> questions like:
> - what if one AT in each "disability type" were to support the API; is
> that enough?
> - what if a collection of AT that represents 25%+ market share in each
> "disability type" were to support the API; is that enough? 50%+ 75%+ ?
> must we reach 95%?
> - is there any distinction to be made about when the API is published?
> (e.g. an API published when the OS comes out, vs. released
> later, after
> AT has established itself via reverse-engineering techniques)
> - what if an API has been published, supported, and used by apps for 1
> year? 2 years? 5 years? (but is not supported by some requisite
> set/percentage of AT)
>
>
> I agree that this is a slippery slope, but it is essentially the same
> sort of slope we have with Web accessibility techniques, and in fact
> with the rest of the technical standards in 1194.21 and
> 1194.22. And we
> face it in any "sufficient techniques" requirement for IT.
>
> IT is being told "do things this way to work with AT" - be it how text
> should be rendered or how the caret exposed, or how to encode
> tables in
> HTML. The presumption is that AT will make use of these techniques to
> make the apps/web sites accessible. Right now there are no
> requirements
> that AT support these techniques prior to IT being told to
> use them, and
> 508 saying that such use is acceptable and sufficient for acquisition.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> >
> > -Randy
> > ATIA
> >
> >
> > *From: *"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> > *Reply-To: *TEITAC Web/Software Subcommittee
> > < = EMAIL ADDRESS REMOVED = >
> > *Date: *Mon, 22 Jan 2007 17:20:11 -0600
> > *To: *"'TEITAC Web/Software Subcommittee'"
> > < = EMAIL ADDRESS REMOVED = >, "'TEITAC General Interface
> > Accessibility Subcommittee'" < = EMAIL ADDRESS REMOVED = >
> > *Cc: *'TEITAC Subpart A Subcommittee'
> > < = EMAIL ADDRESS REMOVED = >
> > *Subject: *Re: [teitac-websoftware] [teitac-general]
> > [teitac-closed]"closed software"
> >
> >
> > Ok
> >
> > So we have established that working with no AT (and not being
> > directly
> > accessible) is not good enough, and working with all AT is too
> > much.
> >
> > How do we draw the line for what is good enough? The AT
> in use by
> > 50% of
> > the people (half can use)? 75% (75% can and 25% can't use)?
> > Some other
> > number?
> >
> >
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> >> Of Peter Korn
> >> Sent: Monday, January 22, 2007 1:09 PM
> >> To: TEITAC General Interface Accessibility Subcommittee
> >> Cc: 'TEITAC Subpart A Subcommittee'; TEITAC Web/Software
> > Subcommittee
> >> Subject: Re: [teitac-websoftware] [teitac-general]
> >> [teitac-closed]"closed software"
> >>
> >> Hi David,
> >>
> >> The issue you raise is present whether or not accessibility
> >> APIs are involved. To me, the essential parts of the
> >> scenario you articulate below are: (1) new computers, latest
> >> software and AT; (2) your choice of AT isn't working with
> >> that latest software. Absent from the scenario is any
> >> mention of whether the latest version of the AT is current or
> >> old (hey, I have the latest version of Slimware
> >> WindowsBridge; too bad it doesn't work on my Windows Vista
> >> system...), and whether a sizable portion - if not perhaps a
> >> majority - of AT do work with those new computers and latest
> > software.
> >>
> >> If we have a set of rules for software to follow and it it
> >> following them, and if further we have lots of the AT for
> >> that platform working with that software, then how much more
> >> is it reasonable to demand of mainstream software vendors?
> >> Whether or not we bring supported APIs into the ruleset, the
> >> situation is essentially the same.
> >>
> >>
> >> To answer your question - no, I wouldn't not suggest that you
> >> are productive in your stipulated situation. Nor would I say
> >> that the combination you are using is accessible to you. But
> >> would a different combination be accessible to you? Quite
> >> possibly so.
> >>
> >> Is it appropriate for 508 to require mainstream IT to be
> >> compatible with every AT product ever shipped for a given platform?
> >>
> >>
> >> Regards,
> >>
> >> Peter Korn
> >> Accessibility Architect,
> >> Sun Microsystems, Inc.
> >>
> >>> Hi Peter,
> >>>
> >>> The incremental approach and rashionalle for it makes me a bit
> >>> uncomfortable. I'm workingg at a brand new job in foof ed. We've
> >>> got new computers with the most up to date software and at.
> >> One of
> >>> the products we use is built on a new api which is minimally
> >>> supported by My AT. I can read text in the app but cannot enter
> >>> text, save files, open files.... would you call me productive?
> >>>
> >>> On Jan 11, 2007, at 1:48 AM, Gregg Vanderheiden wrote:
> >>>
> >>> That feels like it should be but isn't it usually true that
> >> building
> >>> to the
> >>> API doesn't usually make something work without testing and
> >> tweaking
> >>> etc?
> >>>
> >>> Shouldn't the software actually be tested with the AT to make sure
> >>> that the
> >>> API implementation was correct? And that it actually
> >> worked with AT?
> >>>
> >>>
> >>> Gregg
> >>> -- ------------------------------
> >>> Gregg C Vanderheiden Ph.D.
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: = EMAIL ADDRESS REMOVED =
> >>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >>>> Peter Korn
> >>>> Sent: Wednesday, January 10, 2007 11:58 AM
> >>>> To: TEITAC General Interface Accessibility Subcommittee
> >>>> Cc: 'TEITAC Subpart A Subcommittee'; 'TEITAC Web/Software
> >>>> Subcommittee'
> >>>> Subject: Re: [teitac-general]
> >>>> [teitac-websoftware][teitac-closed]"closed software"
> >>>>
> >>>> Hi Gregg,
> >>>>
> >>>> I think "sufficient techniques" can play a role here. As
> >>>> we've said in several discussions, it isn't workable for an
> >>>> app to say "I've implemented some random API that I just
> >>>> invented, so it is now the AT responsibility". At the same
> >>>> time, if we have well established (and well supported by AT)
> >>>> accessibility APIs, then we *do* want apps to go that route.
> >>>>
> >>>> So what if we had a small set of "sufficient technique APIs"
> >>>> - a set that would not grow rapidly, and mostly grow by being
> >>>> paired with the development of new platforms (e.g. a new OS,
> >>>> with its own API and AT).
> >>>> One potential requirement of an API being recognized as
> >> "sufficient"
> >>>> would include some level of AT adoption. The bar shouldn't
> >>>> be too high, but likewise not too low. 508 is, after all,
> >>>> about the gov't inducing market forces to solve accessibility
> >>>> problems.
> >>>>
> >>>> Would that address (or at least somewhat ameliorate) concerns
> >>>> #2 & #3 below?
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Peter Korn
> >>>> Accessibility Architect,
> >>>> Sun Microsystems, Inc.
> >>>>
> >>>>
> >>>>> ...
> >>>>>
> >>>>> 2) the software does something new that AT hasn't seen
> >>>>>
> >>>> before. The software
> >>>>
> >>>>> 'enabled' access - but the AT doesn't work with it.
> >>>>> - this one is interesting.
> >>>>> a) if there is a perfect API that covers all aspects - and
> >>>>>
> >>>> it is clear how
> >>>>
> >>>>> to use it - then one could say that the AT should have
> >>>>>
> >>>> worked with the
> >>>>
> >>>>> software and it is a 'bug' in the AT if it doesn't.
> >>>>> b) if there are many APIs or if the API is not unambiguous
> >>>>>
> >>>> or it is somewhat
> >>>>
> >>>>> an art to get the information from the API then I'm not
> >>>>>
> >>>> sure it can be only
> >>>>
> >>>>> the AT companies responsibility.
> >>>>> - Until the new thing appeared there was no way for the AT
> >>>>>
> >>>> to build to it.
> >>>>
> >>>>> - IT vendors have many many more resources to create new
> >>>>>
> >>>> features or access
> >>>>
> >>>>> problems then AT does to solve them. It can't be a 'you
> >>>>>
> >>>> just need to catch
> >>>>
> >>>>> up to me' situation.
> >>>>> - the APIs usually provide the basic information - but not
> >>>>>
> >>>> the 'interface'.
> >>>>
> >>>>> That is for AT to provide. It takes the software company
> >>>>>
> >>>> time to add the
> >>>>
> >>>>> interface for its new feature (even if it uses old
> >>>>>
> >>>> technology) and so it
> >>>>
> >>>>> would for AT vendors. Time and money. And if software
> >>>>>
> >>>> revamps its
> >>>>
> >>>>> interface it takes a LOT of time and money and testing to
> >>>>>
> >>>> get it right.
> >>>>
> >>>>> Ditto for AT - but where does the time and money all come from.
> >>>>>
> >>>>>
> >>>>> 3) software uses an API not supported by AT.
> >>>>> We discussed this one previously. AT vendors can barely
> >>>>>
> >>>> keep up with
> >>>>
> >>>>> software as it is. Introducing a new API doesn't make AT
> >>>>>
> >>>> appear. And if
> >>>>
> >>>>> there isn't any AT then there isn't any access (for what
> >>>>>
> >>>> ever population
> >>>>
> >>>>> there isn't AT for).
> >>>>>
> >>>>>
> >>>>> The real danger is if we don't 'REQUIRE' a particular API -
> >>>>>
> >>>> because we
> >>>>
> >>>>> 'REQUIRE' AT vendors to support whatever API industry comes
> >>>>>
> >>>> up with (by
> >>>>
> >>>>> saying it is sufficient to have an API).
> >>>>>
> >>>>>
> >>>>> Having said that - I REALLY like the idea of both sides
> >>>>>
> >>>> building to an
> >>>>
> >>>>> API. But
> >>>>> 1) it has to be a good and complete API
> >>>>> 2) AT vendors will still need help keeping up
> >>>>> 3) if there is not AT there is no access. API or not.
> >>>>>
> >>>>> *** The API isn't there to substitute for access - but to
> >>>>>
> >>>> facilitate it. And
> >>>>
> >>>>> make it less work for both sides. ***
> >>>>>
> >>>>> Gregg
> >>>>> -- ------------------------------
> >>>>> Gregg C Vanderheiden Ph.D.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: = EMAIL ADDRESS REMOVED =
> >>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> >>>>>> Of Andi Snow-Weaver
> >>>>>> Sent: Wednesday, January 10, 2007 5:58 AM
> >>>>>> To: TEITAC Web/Software Subcommittee
> >>>>>> Cc: 'TEITAC General Interface Accessibility Subcommittee';
> >>>>>> 'TEITAC Subpart A Subcommittee'
> >>>>>> Subject: Re: [teitac-websoftware]
> >>>>>> [teitac-closed][teitac-general]"closed software"
> >>>>>>
> >>>>>> Gregg asked:
> >>>>>> is
> >>>>>> it?"
> >>>>>>
> >>>>>>
> >>>>>> To which Rex replied:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I didn't really ask this. I proposed that there were levels of
> >>>>>>>
> >>>>>>>
> >>>>>> accessibility, just like you proposed different speeds of
> >>>>>> "door openers."
> >>>>>> I
> >>>>>> there
> >>>>>> to do
> >>>>>> those
> >>>>>> disabilities.
> >>>>>>
> >>>>>> This is a very real situation and is exactly one of the
> >>>>>> general issues brought up in the Web and Software
> >>>>>> subcommittee which we will be discussing today. It happens
> >>>>>> all the time and not just for the newer APIs or those on
> >>>>>> non-Windows platforms. We have found that we can do all of
> >>>>>> the right things with the most well-supported API (MSAA) on
> >>>>>> the most well-supported platform
> >>>>>> (Windows) and prove that we have done so using inspection
> >>>>>> tools. Yet the screen readers sometimes won't work
> >>>>>> sufficiently with the software.
> >>>>>>
> >>>>>> Some would argue that the IT product in this case meets 508.
> >>>>>> Others would argue that it doesn't and point to the
> >>>>>> functional performance criteria. It depends on how you
> >>>>>> interpret support "for" assistive technology. Some lawyers
> >>>>>> would argue that, in the above case, support "for" assistive
> >>>>>> technology has been provided, it's just that the AT isn't
> >>>>>> using it properly.
> >>>>>>
> >>>>>> In our internal process in IBM, we call this being "enabled"
> >>>>>> for accessibility. It means the development team has done
> >>>>>> their part to make it possible for AT to work with it. But
> >>>>>> further customization of the AT may be required to make this
> >>>>>> actually work for someone. The question is, whose
> >>>>>> responsibility is it to ensure that the AT actually works?
> >>>>>>
> >>>>>> In other technology interoperability standards areas, it is
> >>>>>> quite normal to test "to the standard." So when customers
> >>>>>> need things to interoperate they look for things that claim
> >>>>>> conformance to the standard and there is a very high degree
> >>>>>> of probability that they will work.
> >>>>>>
> >>>>>> This is not the situation in 508 where, by some
> >>>>>> interpretations, conformance to the standard may depend on
> >>>>>> third party products which are not required by the regulation
> >>>>>> to conform to the standard. Am I the only one who finds
> >>>>>>
> >>>> this bizarre?
> >>>>
> >>>>>> I can see a lot of merit to Rex's argument for levels of
> >>>>>> accessibility.
> >>>>>>
> >>>>>> Andi
> >>>>>>
> >>>>>>

• Next message in Thread: Peter Korn: "Re: "closed software""
• Previous message in Thread: David Poehlman: "Re: "closed software""