Thread Subject: Re: APIs

From: Gregg Vanderheiden
Date: Sat, Mar 24 2007 10:00 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Rex Lint: "Re: APIs"
• Previous message in thread: Rex Lint: "Re: APIs"
• Messages sorted by: Author | Thread | Date

Good point. Excellent point in fact.
Thanks

I think we should say "greatly reduces" though since APIs are not complete
and things always break on both sides when there is change - unfortunately.

If only we could create the perfect API...... That would be something.

But the better the API the closer we get to this.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Saturday, March 24, 2007 11:45 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] [teitac-general] APIs
>
> Gregg,
>
> In your list of API benefits, I think you missed the biggest
> plus of all for using an API approach: It insulates changes
> in the application and/or the platform (computer architecture
> + operating system) from changes in the AT.
>
>
> The API is a feature that stays constant, release to release,
> so when M/S or SUN or Apple or XYZ comes out with a new
> release, if the same API doesn?t work, THERE'S A BUG, and the
> vendor should fix it. It's like any backwards-compatible
> feature. This means the AT vendor can depend on not having a
> crisis every time there's an update to an OS or an
> application, if they (the AT, the Application vendor, and the
> platform vendor) all use the API.
>
> So no longer will the platform vendor have to worry about
> breaking AT with their new release, and their development
> schedule won't be held hostage by the lack of resources at an
> AT company to re-engineer the interface between the AT and a
> new release of a platform or application every time there's a change.
>
> Rex Lint, Consultant
>      Chair, Section 508 Working Group
>      Information Technology Ass'n of America
>      PH:    603-860-7651
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg Vanderheiden
> Sent: Wednesday, March 21, 2007 1:03 PM
> To: 'TEITAC General Interface Accessibility Subcommittee'
> Cc: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] [teitac-general] APIs
>
> Some observations from the list and discussions and past work
> that has been done on this.
>
>
>
> 1) API's can decrease (often greatly) the amount of work
> needed to create access by AT vendors
>
> 2) They can also reduce the time needed by IT vendors in
> supporting multiple different AT vendors.
>
> 3) From working with many companies it has become clear that
> APIs don't allow products to work together without testing
> and tuning. This is not just an accessibility issue. It is
> true of mainstream APIs as well. Companies have Plug-fests
> all the time and IT companies have large test labs and make
> their engineers available to other companies to help make
> their products work together. So technologies that implement
> APIs must be tested. .
>
> 4) An API by itself does not make a product more accessible
> if there is
> nothing that works with it. The API doesn't make a product usable by
> people with disabilities. It just facilitates the creation
> of AT that can
> make products usable by people with disabilities.
>
> 5) AT can provide access without an API. Some AT works
> without APIs today.
> Though for some types of IT/AT would be very difficult without an API.
>
>
>
>




begin 666 ATT00003.txt
M7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?
M7U-"G1E:71A8RUW96)S;V9T=V%R92!M86EL:6YG(&QI<W0-"G1E:71A8RUW
M96)S;V9T=V%R94!L:7-T+G1E:71A8RYO<F<-"FAT=' Z+R]L:7-T+G1E:71A
K8RYO<F<O;6%I;&UA;B]L:7-T:6YF;R]T96ET86,M=V5B<V]F='=A<F4-"@``
`
end

• Next message in Thread: Rex Lint: "Re: APIs"
• Previous message in Thread: Rex Lint: "Re: APIs"