Thread Subject: Re: Users AT Definition

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
Date: Mon, Jun 18 2007 1:50 PM

Peter:

You wrote:

³... forced to do some amount of AT testing²

³ ... safely blame the AT²

³ ... conjure up a workaround²

I think you may be overlooking the option of actually working together with
AT vendors to ensure compatibility.

As far as your proposed definition goes, it pre-supposes a standard exists ­
which it doesn¹t. If you say ³code to the standards² - what standards do
you mean? Currently, there are no accepted AT-IT interoperability standards
­ only 508, which is not a technical standard, and can¹t be ³coded to².

-Randy
------------------------------------------------
Randy Marsden, P.Eng.
President & CEO, Madentec Limited
ATIA Global Policy Chair

780-450-8926 ext. 223
= EMAIL ADDRESS REMOVED =

>
> From: Peter Wallack < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Fri, 15 Jun 2007 13:36:07 -0700
> To: TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-general] Users AT Definition
>

> I'd propose the following wording to replace 'Users AT':
>
> AT that is itself coded to be inter-operable with products coded to these
> standards.
>
> As for 'coding to the standards' vs. actual AT testing, that is indeed the $1
> million issue. Of course we want to simply code to a standard, just as we do
> for any API. But the Functional Performance criteria require us to supply a
> mode that actually works, so we are forced to do some amount of AT testing.
> But of course we cannot test every possible AT. And if it doesn't work, we
> then must make a judgment call: can we safely blame the AT (and be prepared to
> explain it over and over and over), or should we conjure up a workaround. The
> same issues occur when we test and find problems with the OS and browser, but
> its a bit different because they are much rarer, and the interfaces tend to be
> very well defined 'industry standard' APIs.
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation
>
>
> Tom Brett wrote:
>> [teitac-general] Users AT Definition
>> The use of term such as reasonable, current and common in the standards seem
>> to be appropriate. I am concerned that the conversation tended to talk about
>> using 1 type of AT to test applications. Testing with AT is a good final
>> step in validating a product but the developer needs to be able to say that
>> they have followed the standards. I am aware of products that work with Jaws
>> but will not work with other screen readers or speech to text technology.
>> The vendor developed Jaws scripts to allow the product to work with the
>> product instead of following the Section 508 standards and then says the
>> product meets the Section 508 standards because it works with Jaws.
>>
>>
>>
>> In addition, the AT vendors have a certain amount of responsibility in this
>> also. These vendors need to develop AT that will use commonly available
>> features in the operating system and programming language. For example, if AT
>> does not read a properly coded alternative value of an image (alt=) the
>> problem is with the AT not the EIT. The EIT has been written to the standard.
>> There is nothing more that the developer can do.
>>
>>
>>
>> There are cases when the AT just does not work. About 3 years ago the makers
>> of a popular screen reading software made a mistake and removed the support
>> for JAVA in their product. The screen reader application did not work with
>> Java applications. The problem was not with the software application because,
>> presumably, it was written to the Section 508 standards.
>>
>>
>>
>> If applications and systems follow the technical standards but the AT does
>> not work the problem is with the AT not the product. It may be necessary to
>> tweak the AT to make it more compatible with the network architecture and or
>> the product. Using any type of AT, screen reader, head mouse, blow tube,
>> speech to text, etc. to test a product to determine if it conforms to the
>> Section 508 standards is not good practice. This is particularly true of
>> products that are available to retrieve public information by members of the
>> public. The Government cannot say to a member of the public that the AT they
>> are using was not used in the testing of the product so you will need to
>> change.
>>
>>
>>
>>
>>
>> Tom Brett
>>
>>
>>
>>
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy Marsden
>> Sent: Tuesday, June 12, 2007 10:04 PM
>> To: TEITAC General Interface Accessibility Subcommittee
>> Cc: Jessica M. Brodey; David Dikter
>> Subject: [teitac-general] Users AT Definition
>>
>>
>>
>> Hi General Folks:
>>
>> I apologize neither Jessica nor myself were able to attend yesterday¹s
>> General Subcommittee meeting to represent ATIA. I have read the transcript
>> and see it would have been nice to have had one of us there for the
>> discussion about defining what ³Users¹ AT² means.
>>
>> Here are the points I would have made, had I been on the call:
>>
>> 1. I hear what Phil (and others) are saying about wanting to be able to
>> design to a defined interface, and then testing with select AT to make sure
>> it works. Then, if it doesn¹t work with other AT, the responsibility should
>> be on that other AT as IT must surely have done their job by writing to the
>> spec and conducting limited successful testing. (I hope I have paraphrased
>> his comments correctly ­ if not, please let me know).
>>
>>
>> MY RESPONSE: unfortunately, no such interoperability specification exists
>> today. It would truly be nice if one did; life would be easier for both IT
>> and AT, and almost certainly better for the end-user. But it doesn¹t exist
>> yet, so I don¹t see how we can make it part of what we¹re doing now.
>> Secondly, even if such a standard did exist, I would be very hesitant to say
>> all IT has to do is meet it and they¹re good to go. In practice, there is
>> almost always ³tweaking² that is required for true compatibility ­ even when
>> interoperability standards and API¹s exist. (This is true with any standard
>> ­ for example, we have found a wide range of different current capabilities
>> on USB ports of different computers, notwithstanding a well-defined
>> specification).
>>
>> If the IT company tests with an AT product and finds it to work, and then
>> tests with a second AT product which doesn¹t, it doesn¹t necessarily mean the
>> second AT product has done something wrong. Using my example, perhaps the
>> second AT product requires a higher current (but still within spec) than the
>> first AT product, which the IT product is failing to supply. Or perhaps the
>> second AT product really does have a problem. It could be due to any one of
>> a number of things ­ all of which would likely be much easier to fix with
>> collaboration between the IT and AT companies.
>>
>> For many years, AT operated pretty much in a ³collaboration vacuum² with IT
>> (with notable exceptions). One of the primary benefits of 508 is that it
>> encourages AT and IT collaboration (like what we¹re doing right now). As
>> ATIA, we are leery of anything that may take away that benefit (such as
>> saying all IT has to do is meet a yet-to-be-defined interoperability
>> specification, and they¹re done).
>>
>>
>> As far as the definition goes, I still think we have to keep it vague, and
>> then provide ancillary notes to help provide direction. We talked about
>> using words like ³reasonable², ³readily available², ³current², and ³common².
>>
>> -Randy
>>
>> ------------------------------------------------
>> Randy Marsden, P.Eng.
>> President & CEO, Madentec Limited
>> ATIA Global Policy Chair
>>
>> 780-450-8926 ext. 223
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>>
>>
>>
>>
>>

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