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: Peter Korn
Date: Mon, Feb 05 2007 7:01 AM

Hi David,

> Hi Peter et al, Can we take the approach here that any at built or
> modified after some future date must support the api? Can we
> enccourage establishment of a working relationship between and among
> the various stake holders to move this forward? have we already done
> so?
>

To be clear from the outset - no matter what, API-based solutions cannot
be the *only* way to reach acceptable results. The goal here is that AT
& IT work together to produce an accessible, efficient, and productive
environment for U.S. government employees with disabilities - and of
course for anyone else who choses to follow these standards. Anything
we say in 508 should be with the end results in mind.

While I personally believe that API-based solutions are the best way to
achieve this goal, and also to do so at the lowest cost, they are not
the only way and I will vehemently argue against a change to 508 that
limits innovation to using *only* APIs to achieve results.

So long as API-based solutions remain the realm of updates to the
technical standards in Section B - while leaving unchanged (or perhaps
even strengthening) the equivalent facilitation portion of Section A, I
think we will be in fine here.

Now, to your questions.

Once, long ago, I spent 5 years as an AT vendor, and I strongly
empathize with the arguments that forcing AT vendors to do go through
additional hurdles for the relatively small market of the U.S.
government may result in some pulling out of that market. I think
before we consider such action, we should first get feedback from U.S.
government customers on how well AT is supporting those aspects of the
current technical standards that IT is implementing to. For example, we
have several web provisions that require IT to expose certain
information. My understanding from discussions in the Web & Software
subcommittee is that now AT does a good job in using that exposed
information (though perhaps it didn't the day those mechanisms were
announced).

My own experience is that AT vendors by and large are very interested in
taking advantage of well documented and well supported mechanisms for
getting at the information they need to provide a rich and accessible
experience for their users. The problems come in when those mechanisms
aren't sufficient, or aren't implemented by a large enough portion of
their market to be worthwhile for them to pursue it.

I personally hope that we can address AT support via the marketplace.
If many/most of IT are using the same techniques and interfaces to
expose all of the necessary accessibility information, then AT will use
those interfaces because they will find it the easiest way to support
the greatest number of applications in the marketplace. I far prefer
that to forcing AT to doing anything.

The key for me is that we are moving the industry forward by clearly
describing a set of best practices - describing a powerful and efficient
way to be compatible with AT, without limiting IT (and AT) in their
options to come up with other ways if they find those other ways suit
them and the overall goals better.


As to encouraging greater working relationships between the various
stakeholders, I think that is already happening quite a lot. I believe
we will have a presentation that talks to some of this in the Thursday
morning segment of TEITAC #3 next week.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Thanks!
>
> On Feb 1, 2007, at 12:29 AM, Peter Korn wrote:
>
> Hi Randy,
>
> Sorry for the delay in replying; I'm catching up on old e-mail...
>
>
>> /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...
>>
>
> I'm suggesting that there are boundaries, with what is reasonable
> somewhere in the middle. Each application inventing its own API which
> provides all the "necessary" information (whatever we define that to be)
> is untenable. AT cannot keep up with that; we're left in perhaps a
> marginally better situation than we are in now - where AT has to
> potentially special case every app out there. So I suggest that this is
> untenable. [Mind you, some might say that under today's 508 language
> this is perfectly acceptable - the information AT needs is exposed so
> the app is done - same equally untenable situation].
>
> At the same time, we have in a product like Slimware WindowsBridge an
> example of an AT that is no longer supported, though some may still use
> it. Requiring that all AT, including something like WindowsBridge,
> support a particular API before it can be used by apps, is likewise
> untenable.
>
> Trying to narrow these boundaries somewhat toward eachother, we have
> questions like:
> - what if one AT in each "disability type" were to support the API; is
> that enough?
> - what if a collection of AT that represents 25%+ market share in each
> "disability type" were to support the API; is that enough? 50%+ 75%+ ?
> must we reach 95%?
> - is there any distinction to be made about when the API is published?
> (e.g. an API published when the OS comes out, vs. released later, after
> AT has established itself via reverse-engineering techniques)
> - what if an API has been published, supported, and used by apps for 1
> year? 2 years? 5 years? (but is not supported by some requisite
> set/percentage of AT)
>
>
> I agree that this is a slippery slope, but it is essentially the same
> sort of slope we have with Web accessibility techniques, and in fact
> with the rest of the technical standards in 1194.21 and 1194.22. And we
> face it in any "sufficient techniques" requirement for IT.
>
> IT is being told "do things this way to work with AT" - be it how text
> should be rendered or how the caret exposed, or how to encode tables in
> HTML. The presumption is that AT will make use of these techniques to
> make the apps/web sites accessible. Right now there are no requirements
> that AT support these techniques prior to IT being told to use them, and
> 508 saying that such use is acceptable and sufficient for acquisition.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>> -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