Thread Subject: Re: "closed software"

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Randy Marsden (Home)
Date: Tue, Jan 23 2007 12:40 AM

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...

-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
>>>>>> > >>>>
>>>>>> > >>>>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University