Thread Subject: Re: "closed software"

From: Gregg Vanderheiden
Date: Mon, Jan 22 2007 4:30 PM

• 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: Gregg Vanderheiden: "Re: "closed software""
• Messages sorted by: Author | Thread | Date

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