Thread Subject: Re: "closed software"

From: Gregg Vanderheiden
Date: Wed, Jan 10 2007 7:50 AM

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

Hmmmmm

There are, i think three parts to this. Or three situation that could lead
to AT not working with software.



1) There is a bug in the AT. It worked with the last version of the AT but
the new one had a bug. This is the AT's problem I would say.

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: Gregg Vanderheiden: "Re: "closed software""
• Previous message in Thread: David Poehlman: "Re: "closed software""