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: Gregg Vanderheiden
Date: Thu, Jan 11 2007 9:35 PM

It occurs to me that there are some places where an API would be sufficient
and others where testing with AT would be needed.

Screen readers look like the latter.

Have to think more about this though.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, January 11, 2007 7:14 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 Gregg,
>
> The ideal scenario is that an AT + an application that
> exposes the API properly will yield a good level of access.
> Additional scripting/customizatin/tweeking on the AT part can
> then build on that level of access toward improved efficiency
> and productivity. We are finding this ideal scenario in a
> good number of GNOME apps on the UNIX desktop today.
>
> For example, on UNIX the Orca screen reader + the gedit text
> editor worked pretty well with no gedit-specific
> customization on Orca's part.
> Orca was able to read all of the menus, text, and dialogs.
> It was able to provide flat review for the entire
> application. And it was able to convey text attribute
> information. On top of that, an Orca script provides special
> handling of the spell check dialog and the find dialog
> - in both cases automatically reading the appropriate parts
> of both that dialog and the main body of text as the user
> interacts with those dialogs (the Orca script for gedit also
> does a few other things - if you are interested, see
> http://svn.gnome.org/viewcvs/*checkout*/orca/trunk/src/orca/sc
> ripts/gedit.py?rev=1664&content-type=text%2Fplain
> for the actual script code).
>
> I don't mean to suggest that you wouldn't want to test the
> app with the AT. But in the Windows world we have dozens of
> AT products (and multiplied by dozens of versions, you get a
> very large test matrix).
> Thorough testing against all AT products isn't very
> practical. And thorough testing by AT companies of all IT
> products is utterly impossible. Which means that the best
> effective thing to do is for both IT and AT companies to test
> against an API.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > 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