Thread Subject: Re: 3-w at-interoperability and 3-V

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: Wed, Sep 05 2007 1:55 PM

Hi Allen,

The conclusion of your example isn't 100% accurate. If the IT product
can demonstrate that it is providing all of the information via an API
inspection tool (e.g. Ferret for Java, Accercizer in GNOME), then we
know that it is *likely* that IT is doing what it should. The issue is
more complex because AT only knows *when* to ask by receiving events
about the changes of the UI (the AT would get the name of the button if
asked, but it never knew that the button received focus).

So, a tool like Ferret/Accercizer can be a negative test (if the info
isn't there, we KNOW the problem is with IT).

But to do it properly, you would also want a canonical application that
is a known good test of API info exposure, and then further test whether
AT did what it should with that app (e.g. the SwingSet app in Java; or
gtk-demo in GNOME). If the AT failed to demonstrate that it did the
right thing with that canonical app, then we have a negative test for
the AT.

This pair of symmetrical negative tests is very helpful - it moves
things forward *tremendously*. But in the case where by the IT can
demonstrate it is providing info, and AT can demonstrate that it uses
properly provided info, we get to the point that AT & IT need to sit
down and hash things out in more detail.


Note: this is the same situation as with something like a printer & an
OS & an app. My app, printing through the OS, might work with printers
generally but fail to print with the Acme printer model 7. Likewise,
the Acme printer model 7 might print documents from applications in
general, but fails to print documents from the WidgetCorp office suite.
Once we get to that kind of situation, the only solution is for Acme &
WidgetCorp to sit down and work things out, debugging them together.

Note: where we are today is that in virtually all cases Acme &
WidgetCorp have to get together and work things out, without the
agency/buyer having any ability to do any kind of (negative) testing.
So this is a huge improvement. But it is not perfection.


Also, this doesn't say much about the efficiency and productivity of use
- e.g. whether something like a screen reader has a script for a
particular workflow task (like spellchecking) to make that task as
efficient as it might be.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Yeah, thinking Ferret here.
> If they are behind the times maybe they need think catching up?
>
> I think a semi-standardized object inspection functionality available
> widely would go a long way towards eliminating the screen reader from
> normal testing procedures.
>
> So, for example, if I know the name of an element is there, its value,
> its relationship, etc--and the screen reader isn't reading it right,
> its the screen readers fault.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
> ------------------------------------------------------------------------
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Peter Korn
> *Sent:* Wednesday, September 05, 2007 2:26 PM
> *To:* TEITAC Web/Software Subcommittee
> *Subject:* Re: [teitac-websoftware] 3-w at-interoperability and 3-V
>
> Hi Allen,
>
> That is interesting. It would actually be easy to add that to
> existing 3-V, where we have a new bullet, something like "be able to
> demonstrate that all of this information is provided to AT through the
> use of an accessibility services exploration tool". In parallel, we
> might note that such a tool should be provided by a platform, as part
> of the platform accessibility services.
>
> I don't believe this is in either ISO or WCAG/ATAG has anything like
> this, so doing this would mean we have a country-specific,
> non-harmonized requirement.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>> Hi all:
>>
>> I won't get my comments in today on the AT Interoperability area so
>> will post here:
>>
>> AT is used to test because there are mostly no reliable testing tools
>> easily available that will show what object information is being
>> exposed. AT requires a great degree of knowledge to be used as a
>> testing tool, and often fails in that purpose. The trick is to
>> determine if the bug is the AT, the platform, or the application, and
>> this can be really tricky.
>>
>> So:
>>
>> I suggest that we add an item in to 3-w to require that platforms
>> provide a method to allow the user to walk through or "inspect"
>> objects to identify if they meet the requirements from 3-v.
>>
>> In web this is different since so many testing tools can do this,
>> even in automated ways.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>>
>> <!--[if !supportLists]--><!--[endif]-->
>> ------------------------------------------------------------------------
>>
>>

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