Thread Subject: Re: "closed software"

From: Gregg Vanderheiden
Date: Thu, Jan 11 2007 12:05 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: Gregg Vanderheiden: "Re: "closed software""
• Messages sorted by: Author | Thread | Date

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: Gregg Vanderheiden: "Re: "closed software""