Expanding the web's potential for people with disabilities

Getting Started

Introduction to web accessibility

WebAIM Training

May 21-22
Training Details

From the Blog

Community

You are here: Home > TEITAC Archives > Mailing List Archives

Thread Subject: Re: "closedsoftware"

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.

Return to this mailing list's archives

Next message

From: Peter Korn
Date: Tue, Dec 19 2006 1:30 PM
Subject: Re: "closedsoftware"

Hi Jim, Gregg,

To expand on Gregg's answer #1 to your question about closed software:

> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow anything to access
> what it has on screen and which reads keyboard registers directly to avoid
> tampering or 'remote' typing.
>

Sun's Trusted Solaris 9 - and especially the "multi-level/multi-label
security mode" is a real life example of this. In order to ensure the
highest levels of security for sales to customers like the National
Security Agency, Trusted Solaris goes to great lengths to ensure that
applications are siloed apart from one another. Applications cannot get
access to the keyboard or mouse directly - they only have very limited
access when that particular application is focused.

By the way, we are working on explicitly supporting accessibility in
forthcoming versions of Trusted Solaris - through accessibility APIs
that can only be used by AT software that has been explicitly installed
and given the privileges to have that API level of access to other
applications. For such security sensitive environments, we see
absolutely no other approach that meet both security & accessibility
requirements.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Wed, Dec 27 2006 12:30 PM
Subject: Re: "closedsoftware"

Sorry to chime in so late on this, but there should never be a
suggestion that anyone give up on federal sales!

There are many products and services that have no designed in
accessibility. That works out into products that are in actually fully
accessible because they developed using standard toolkits and just
didn't test for accessibility or products that, of course, aren't
accessible. But if there is a business need for the product, we are
going to procure it, if there is no other product.

We will choose the most accessible if more than one meets our business
needs, but the right mindset in this is critical! Vendors need to
_compete_ not quit!

Regards,

Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, December 22, 2006 4:32 PM
To: 'TEITAC self contained/closed products subcommittee';
'TEITAC Web/Software Subcommittee'
Cc: 'TEITAC General Interface Accessibility Subcommittee'
Subject: Re: [teitac-general] [teitac-closed]
[teitac-websoftware] "closedsoftware"

I was quoting Gregg's comments about what to include or exclude
in any "closed" determination. I *thought* I was speaking very much in
favor of AT innovation, but maybe I wasn't clear. Here's what I mean.
Let's look at 3 cases for an "appliance"-type product:

1. has native accessibility (built-in accessibility features)
2. has no native accessibility, but there is AT
3. has no native accessibility, and no current AT

The goal is to move more products into categories #1 and #2.
Not to eliminate #2, but to expand it. More consumer/procurer choice.

A mainstream company with a #3 product has 3 options:

a. give up on federal sales
b. add native accessibility
c. partner with or otherwise encourage an AT company to develop
an AT solution for the product

Previous message | Next message

From: Gregg Vanderheiden
Date: Tue, Jan 02 2007 11:05 PM
Subject: Re: "closedsoftware"

Hi Norman,

I agree with your premise that there shouldn't be any closed software.

But if there is software that is closed (not accessible to AT) for any
reason (business, technical or security) then we do want to require that it
is accessible - no? And I believe that there will be legitimate arguments
for some places where the software will be closed - and/or that there will
be no AT developed for or that can be used with the product.

I'm not talking about desktop computers necessarily.

What if we just said

1) that products need to be accessible either via available assistive
technology or directly accessible.

2) that products that require productivity (e.g. workstations) need to be
accessible to assistive technologies to allow matching of user abilities
necessary to achieve high levels of productivity.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Wednesday, December 27, 2006 2:54 PM
> To: TEITAC self contained/closed products subcommittee;
> TEITAC Web/Software Subcommittee
> Cc: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>
> Since I earlier offered a different perspective on "closed
> software", I thought I would respond to each item.
>
> 1. Security reasons: Security should be a part of a
> requirement in the same way accessibility should be a part of
> the requirement for a product. First, security options _CAN_
> be accessible (e.g., accessible CAPTCHAs or accessible login
> screens). Second, where there is a technical determination
> that no access to application programming interfaces (APIs)
> that work with assistive technology is allowed, there is a
> business justification. No matter what assistive technology
> can do, if the system designed to block user interaction to
> only one type of system interface for business reasons, that
> is an exception. However, I'd be amiss if I didn't say see "First".
>
> 2. Besides semantics, and debating among friends, software
> can't run without an operating system unless it, itself, IS
> the operating system.
>
> 3. What is the point of making a classification of "CLOSED SOFTWARE"?
> What does it mean to us in context of Section 508? Your
> example is one of being accessible through design. I'd say
> the example doesn't help the argument and problem we are
> trying to solve (if you'll please forgive me). We are
> concerned when software doesn't work with assistive
> technology and isn't designed to be accessible. I'd also say
> I have the expectation that this software is generally only
> used in conjunction with specialized hardware. Firefox web
> browser was considered to be too small a market for certain
> AT vendors. What does that mean? I think they have an API. I
> think this is complex interaction of _accessibility
> interfaces_ dependent on the operating system. Sorry, I'm an
> Amiga/Windows/OSX/Linux user and it varies considerably. It
> is too easy to just think in context of one platform,
> especially when embedded operating systems in phones are so
> plentiful and experiencing these same issues. Sorry to
> ramble, I think I need to discuss this some more.
>
> 4. Platform software issues are interesting. Is commercial
> availability exemptions? Tying it to vendor product and
> 'official' support is dangerous too; I'm sure my MS Windows
> vendor doesn't support me running Linux on my corporate
> desktop, but the screen reader and web browser works just
> fine for most of my needs. I think that is close to the
> earlier iPod firmware upgrade. But who cares? Even if a 3rd
> party or Apple made the software as an add-on to the product
> it can be made accessible. The debate so far has focused on
> the vendor not developing assistive technology. Third parties
> do and you can make things accessible without assistive technology.
>
> Sorry to disagree, but the closed software approach doesn't
> work well for Section 508 evaluation. I can't help but feel
> we're not asking the right questions. DRM is bad for
> end-users, security typically negatively impacts end-user
> experience, and accessibility is all about the user!
> This discussion is really useful for questioning vendors and
> how they support our business/agency. I don't think finding
> justification for closed software means we should place a
> label on software and treat it any differently from any other
> software. Closed software should be accessible and follow the
> same technical standards as any other software.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Tuesday, December 19, 2006 12:45 PM
> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> Web/Software Subcommittee'
> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-closed] "closed software"
>
>
> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow
> anything to access
> what it has on screen and which reads keyboard registers directly to
> avoid
> tampering or 'remote' typing.
>
> 2 - Software designed to run on a product without and
> operating system.
>
> 3 - Software that has no API for AT - but instead has built in
> accessibility
> since there is no AT vendor who will work with and support the unique
> capability of the software because the market is too small for AT
> vendors.
>
> 4 - Something like Randy pointed to (see just below). The hardware is
> not
> closed since new software can be loaded. But the platform/software is
> closed.
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 3:40 AM
Subject: Re: "closedsoftware"

greg, am I to understand then that your #2 excludes the Mac which has
its ownn AT?

On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:

Hi Norman,

I agree with your premise that there shouldn't be any closed software.

But if there is software that is closed (not accessible to AT) for any
reason (business, technical or security) then we do want to require
that it
is accessible - no? And I believe that there will be legitimate
arguments
for some places where the software will be closed - and/or that there
will
be no AT developed for or that can be used with the product.

I'm not talking about desktop computers necessarily.

What if we just said

1) that products need to be accessible either via available assistive
technology or directly accessible.

2) that products that require productivity (e.g. workstations) need
to be
accessible to assistive technologies to allow matching of user abilities
necessary to achieve high levels of productivity.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Wednesday, December 27, 2006 2:54 PM
> To: TEITAC self contained/closed products subcommittee;
> TEITAC Web/Software Subcommittee
> Cc: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>
> Since I earlier offered a different perspective on "closed
> software", I thought I would respond to each item.
>
> 1. Security reasons: Security should be a part of a
> requirement in the same way accessibility should be a part of
> the requirement for a product. First, security options _CAN_
> be accessible (e.g., accessible CAPTCHAs or accessible login
> screens). Second, where there is a technical determination
> that no access to application programming interfaces (APIs)
> that work with assistive technology is allowed, there is a
> business justification. No matter what assistive technology
> can do, if the system designed to block user interaction to
> only one type of system interface for business reasons, that
> is an exception. However, I'd be amiss if I didn't say see "First".
>
> 2. Besides semantics, and debating among friends, software
> can't run without an operating system unless it, itself, IS
> the operating system.
>
> 3. What is the point of making a classification of "CLOSED SOFTWARE"?
> What does it mean to us in context of Section 508? Your
> example is one of being accessible through design. I'd say
> the example doesn't help the argument and problem we are
> trying to solve (if you'll please forgive me). We are
> concerned when software doesn't work with assistive
> technology and isn't designed to be accessible. I'd also say
> I have the expectation that this software is generally only
> used in conjunction with specialized hardware. Firefox web
> browser was considered to be too small a market for certain
> AT vendors. What does that mean? I think they have an API. I
> think this is complex interaction of _accessibility
> interfaces_ dependent on the operating system. Sorry, I'm an
> Amiga/Windows/OSX/Linux user and it varies considerably. It
> is too easy to just think in context of one platform,
> especially when embedded operating systems in phones are so
> plentiful and experiencing these same issues. Sorry to
> ramble, I think I need to discuss this some more.
>
> 4. Platform software issues are interesting. Is commercial
> availability exemptions? Tying it to vendor product and
> 'official' support is dangerous too; I'm sure my MS Windows
> vendor doesn't support me running Linux on my corporate
> desktop, but the screen reader and web browser works just
> fine for most of my needs. I think that is close to the
> earlier iPod firmware upgrade. But who cares? Even if a 3rd
> party or Apple made the software as an add-on to the product
> it can be made accessible. The debate so far has focused on
> the vendor not developing assistive technology. Third parties
> do and you can make things accessible without assistive technology.
>
> Sorry to disagree, but the closed software approach doesn't
> work well for Section 508 evaluation. I can't help but feel
> we're not asking the right questions. DRM is bad for
> end-users, security typically negatively impacts end-user
> experience, and accessibility is all about the user!
> This discussion is really useful for questioning vendors and
> how they support our business/agency. I don't think finding
> justification for closed software means we should place a
> label on software and treat it any differently from any other
> software. Closed software should be accessible and follow the
> same technical standards as any other software.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Tuesday, December 19, 2006 12:45 PM
> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> Web/Software Subcommittee'
> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-closed] "closed software"
>
>
> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow
> anything to access
> what it has on screen and which reads keyboard registers directly to
> avoid
> tampering or 'remote' typing.
>
> 2 - Software designed to run on a product without and
> operating system.
>
> 3 - Software that has no API for AT - but instead has built in
> accessibility
> since there is no AT vendor who will work with and support the unique
> capability of the software because the market is too small for AT
> vendors.
>
> 4 - Something like Randy pointed to (see just below). The hardware is
> not
> closed since new software can be loaded. But the platform/software is
> closed.
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 3:45 AM
Subject: Re: "closedsoftware"

Previous message | Next message

From: Andrew Kirkpatrick
Date: Wed, Jan 03 2007 8:00 AM
Subject: Re: "closedsoftware"

David,
The Mac OS has an accessibility API that is capable of supporting
assistive technologies - it just happens that Apple made their own, but
an outside company could develop a screen reader or other AT for that
OS.
AWK

David wrote:
greg, am I to understand then that your #2 excludes the Mac which has
its ownn AT?

Greg wrote:
2) that products that require productivity (e.g. workstations) need to
be accessible to assistive technologies to allow matching of user
abilities necessary to achieve high levels of productivity.

Previous message | Next message

From: Andrew Kirkpatrick
Date: Wed, Jan 03 2007 8:20 AM
Subject: Re: "closedsoftware"

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 03 2007 1:10 PM
Subject: Re: "closedsoftware"

Hi Gregg,

I don't understand this. Is it part of the definition of AT that it
comes from a 3rd party, separate from the OS? Or can it be the same
party as the OS, but just not with the OS (e.g. ScreenReader/2 for OS/2)?

Separately, today in the Web & Software SC call, Andi asked about non-AT
voice recognition software (is it only AT if it is called "AT"?).

I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and later),
and Gnopernicus & GOK (bundled with Solaris 10), and GOK & Orca (bundled
with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly the same way that
we (now) say that WordPad is an application (even though it is bundled
with Windows).

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> I thought of that as I wrote it.
>
> Well, since it is built into the OS, the application that work with it would
> be directly accessible since they are accessible without needing any AT.
> Remember that any software with access built in would need to rely on OS
> functions (speech, sound, keyboard etc). this would also rely on the
> voiceover functionality.
>
> Since they have an API - it would ALSO be compatible with any AT that was
> out there.
>
> Having an API only though - without AT support would not be accessible (i.e.
> usable with people who have disabilities) if there was no AT. That is why
> Apple built it into their system and have an API. They support AT but are
> not subject to AT availability - which was a problem for them - at least for
> screen readers.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> David Poehlman
>> Sent: Wednesday, January 03, 2007 4:38 AM
>> To: TEITAC Web/Software Subcommittee
>> Cc: 'TEITAC self contained/closed products subcommittee';
>> 'TEITAC General Interface Accessibility Subcommittee'
>> Subject: Re: [teitac-general] [teitac-websoftware]
>> [teitac-closed] "closed software"
>>
>> greg, am I to understand then that your #2 excludes the Mac
>> which has its ownn AT?
>>
>> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>>
>> Hi Norman,
>>
>> I agree with your premise that there shouldn't be any closed software.
>>
>> But if there is software that is closed (not accessible to
>> AT) for any reason (business, technical or security) then we
>> do want to require that it
>> is accessible - no? And I believe that there will be legitimate
>> arguments
>> for some places where the software will be closed - and/or
>> that there will be no AT developed for or that can be used
>> with the product.
>>
>> I'm not talking about desktop computers necessarily.
>>
>> What if we just said
>>
>> 1) that products need to be accessible either via available
>> assistive technology or directly accessible.
>>
>> 2) that products that require productivity (e.g.
>> workstations) need to be accessible to assistive technologies
>> to allow matching of user abilities necessary to achieve high
>> levels of productivity.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>
>> Of Robinson,
>>
>>> Norman B - Washington, DC
>>> Sent: Wednesday, December 27, 2006 2:54 PM
>>> To: TEITAC self contained/closed products subcommittee; TEITAC
>>> Web/Software Subcommittee
>>> Cc: TEITAC General Interface Accessibility Subcommittee
>>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>>>
>>> Since I earlier offered a different perspective on "closed
>>>
>> software",
>>
>>> I thought I would respond to each item.
>>>
>>> 1. Security reasons: Security should be a part of a
>>>
>> requirement in the
>>
>>> same way accessibility should be a part of the requirement for a
>>> product. First, security options _CAN_ be accessible (e.g.,
>>>
>> accessible
>>
>>> CAPTCHAs or accessible login screens). Second, where there is a
>>> technical determination that no access to application programming
>>> interfaces (APIs) that work with assistive technology is allowed,
>>> there is a business justification. No matter what assistive
>>>
>> technology
>>
>>> can do, if the system designed to block user interaction to
>>>
>> only one
>>
>>> type of system interface for business reasons, that is an
>>>
>> exception.
>>
>>> However, I'd be amiss if I didn't say see "First".
>>>
>>> 2. Besides semantics, and debating among friends, software
>>>
>> can't run
>>
>>> without an operating system unless it, itself, IS the operating
>>> system.
>>>
>>> 3. What is the point of making a classification of "CLOSED
>>>
>> SOFTWARE"?
>>
>>> What does it mean to us in context of Section 508? Your
>>>
>> example is one
>>
>>> of being accessible through design. I'd say the example
>>>
>> doesn't help
>>
>>> the argument and problem we are trying to solve (if you'll please
>>> forgive me). We are concerned when software doesn't work with
>>> assistive technology and isn't designed to be accessible.
>>>
>> I'd also say
>>
>>> I have the expectation that this software is generally only used in
>>> conjunction with specialized hardware. Firefox web browser was
>>> considered to be too small a market for certain AT vendors.
>>>
>> What does
>>
>>> that mean? I think they have an API. I think this is complex
>>> interaction of _accessibility interfaces_ dependent on the
>>>
>> operating
>>
>>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
>>> considerably. It is too easy to just think in context of
>>>
>> one platform,
>>
>>> especially when embedded operating systems in phones are so
>>>
>> plentiful
>>
>>> and experiencing these same issues. Sorry to ramble, I
>>>
>> think I need to
>>
>>> discuss this some more.
>>>
>>> 4. Platform software issues are interesting. Is commercial
>>> availability exemptions? Tying it to vendor product and 'official'
>>> support is dangerous too; I'm sure my MS Windows vendor doesn't
>>> support me running Linux on my corporate desktop, but the screen
>>> reader and web browser works just fine for most of my
>>>
>> needs. I think
>>
>>> that is close to the earlier iPod firmware upgrade. But who cares?
>>> Even if a 3rd party or Apple made the software as an add-on to the
>>> product it can be made accessible. The debate so far has focused on
>>> the vendor not developing assistive technology. Third
>>>
>> parties do and
>>
>>> you can make things accessible without assistive technology.
>>>
>>> Sorry to disagree, but the closed software approach doesn't
>>>
>> work well
>>
>>> for Section 508 evaluation. I can't help but feel we're not
>>>
>> asking the
>>
>>> right questions. DRM is bad for end-users, security typically
>>> negatively impacts end-user experience, and accessibility
>>>
>> is all about
>>
>>> the user!
>>> This discussion is really useful for questioning vendors
>>>
>> and how they
>>
>>> support our business/agency. I don't think finding
>>>
>> justification for
>>
>>> closed software means we should place a label on software
>>>
>> and treat it
>>
>>> any differently from any other software. Closed software should be
>>> accessible and follow the same technical standards as any other
>>> software.
>>>
>>> Regards,
>>>
>>>
>>> Norman B. Robinson
>>> Section 508 Coordinator
>>> IT Governance, US Postal Service
>>> phone: 202.268.8246
>>>
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
>>> Vanderheiden
>>> Sent: Tuesday, December 19, 2006 12:45 PM
>>> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
>>> Web/Software Subcommittee'
>>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
>>> Subject: Re: [teitac-closed] "closed software"
>>>
>>>
>>> Some possible examples of closed software.
>>>
>>> Maybe some things like: (numbered only to facilitate discussion)
>>>
>>> 1 - Software that for security reasons does not allow anything to
>>> access what it has on screen and which reads keyboard registers
>>> directly to avoid tampering or 'remote' typing.
>>>
>>> 2 - Software designed to run on a product without and operating
>>> system.
>>>
>>> 3 - Software that has no API for AT - but instead has built in
>>> accessibility since there is no AT vendor who will work with and
>>> support the unique capability of the software because the market is
>>> too small for AT vendors.
>>>
>>> 4 - Something like Randy pointed to (see just below). The
>>>
>> hardware is
>>
>>> not closed since new software can be loaded. But the
>>> platform/software is closed.
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 03 2007 1:15 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 6:50 PM
Subject: Re: "closedsoftware"

the difference with word pad is tthat it does not act as an interface
to the rest of windows.

On Jan 3, 2007, at 3:07 PM, Peter Korn wrote:

Hi Gregg,

I don't understand this. Is it part of the definition of AT that it
comes from a 3rd party, separate from the OS? Or can it be the same
party as the OS, but just not with the OS (e.g. ScreenReader/2 for OS/
2)?

Separately, today in the Web & Software SC call, Andi asked about non-AT
voice recognition software (is it only AT if it is called "AT"?).

I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and later),
and Gnopernicus & GOK (bundled with Solaris 10), and GOK & Orca (bundled
with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly the same way that
we (now) say that WordPad is an application (even though it is bundled
with Windows).

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> I thought of that as I wrote it.
>
> Well, since it is built into the OS, the application that work with
> it would
> be directly accessible since they are accessible without needing
> any AT.
> Remember that any software with access built in would need to rely
> on OS
> functions (speech, sound, keyboard etc). this would also rely on the
> voiceover functionality.
>
> Since they have an API - it would ALSO be compatible with any AT
> that was
> out there.
>
> Having an API only though - without AT support would not be
> accessible (i.e.
> usable with people who have disabilities) if there was no AT. That
> is why
> Apple built it into their system and have an API. They support AT
> but are
> not subject to AT availability - which was a problem for them - at
> least for
> screen readers.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> David Poehlman
>> Sent: Wednesday, January 03, 2007 4:38 AM
>> To: TEITAC Web/Software Subcommittee
>> Cc: 'TEITAC self contained/closed products subcommittee';
>> 'TEITAC General Interface Accessibility Subcommittee'
>> Subject: Re: [teitac-general] [teitac-websoftware]
>> [teitac-closed] "closed software"
>>
>> greg, am I to understand then that your #2 excludes the Mac
>> which has its ownn AT?
>>
>> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>>
>> Hi Norman,
>>
>> I agree with your premise that there shouldn't be any closed
>> software.
>>
>> But if there is software that is closed (not accessible to
>> AT) for any reason (business, technical or security) then we
>> do want to require that it
>> is accessible - no? And I believe that there will be legitimate
>> arguments
>> for some places where the software will be closed - and/or
>> that there will be no AT developed for or that can be used
>> with the product.
>>
>> I'm not talking about desktop computers necessarily.
>>
>> What if we just said
>>
>> 1) that products need to be accessible either via available
>> assistive technology or directly accessible.
>>
>> 2) that products that require productivity (e.g.
>> workstations) need to be accessible to assistive technologies
>> to allow matching of user abilities necessary to achieve high
>> levels of productivity.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>
>> Of Robinson,
>>
>>> Norman B - Washington, DC
>>> Sent: Wednesday, December 27, 2006 2:54 PM
>>> To: TEITAC self contained/closed products subcommittee; TEITAC
>>> Web/Software Subcommittee
>>> Cc: TEITAC General Interface Accessibility Subcommittee
>>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>>>
>>> Since I earlier offered a different perspective on "closed
>>>
>> software",
>>
>>> I thought I would respond to each item.
>>>
>>> 1. Security reasons: Security should be a part of a
>>>
>> requirement in the
>>
>>> same way accessibility should be a part of the requirement for a
>>> product. First, security options _CAN_ be accessible (e.g.,
>>>
>> accessible
>>
>>> CAPTCHAs or accessible login screens). Second, where there is a
>>> technical determination that no access to application programming
>>> interfaces (APIs) that work with assistive technology is allowed,
>>> there is a business justification. No matter what assistive
>>>
>> technology
>>
>>> can do, if the system designed to block user interaction to
>>>
>> only one
>>
>>> type of system interface for business reasons, that is an
>>>
>> exception.
>>
>>> However, I'd be amiss if I didn't say see "First".
>>>
>>> 2. Besides semantics, and debating among friends, software
>>>
>> can't run
>>
>>> without an operating system unless it, itself, IS the operating
>>> system.
>>>
>>> 3. What is the point of making a classification of "CLOSED
>>>
>> SOFTWARE"?
>>
>>> What does it mean to us in context of Section 508? Your
>>>
>> example is one
>>
>>> of being accessible through design. I'd say the example
>>>
>> doesn't help
>>
>>> the argument and problem we are trying to solve (if you'll please
>>> forgive me). We are concerned when software doesn't work with
>>> assistive technology and isn't designed to be accessible.
>>>
>> I'd also say
>>
>>> I have the expectation that this software is generally only used in
>>> conjunction with specialized hardware. Firefox web browser was
>>> considered to be too small a market for certain AT vendors.
>>>
>> What does
>>
>>> that mean? I think they have an API. I think this is complex
>>> interaction of _accessibility interfaces_ dependent on the
>>>
>> operating
>>
>>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
>>> considerably. It is too easy to just think in context of
>>>
>> one platform,
>>
>>> especially when embedded operating systems in phones are so
>>>
>> plentiful
>>
>>> and experiencing these same issues. Sorry to ramble, I
>>>
>> think I need to
>>
>>> discuss this some more.
>>>
>>> 4. Platform software issues are interesting. Is commercial
>>> availability exemptions? Tying it to vendor product and 'official'
>>> support is dangerous too; I'm sure my MS Windows vendor doesn't
>>> support me running Linux on my corporate desktop, but the screen
>>> reader and web browser works just fine for most of my
>>>
>> needs. I think
>>
>>> that is close to the earlier iPod firmware upgrade. But who cares?
>>> Even if a 3rd party or Apple made the software as an add-on to the
>>> product it can be made accessible. The debate so far has focused on
>>> the vendor not developing assistive technology. Third
>>>
>> parties do and
>>
>>> you can make things accessible without assistive technology.
>>>
>>> Sorry to disagree, but the closed software approach doesn't
>>>
>> work well
>>
>>> for Section 508 evaluation. I can't help but feel we're not
>>>
>> asking the
>>
>>> right questions. DRM is bad for end-users, security typically
>>> negatively impacts end-user experience, and accessibility
>>>
>> is all about
>>
>>> the user!
>>> This discussion is really useful for questioning vendors
>>>
>> and how they
>>
>>> support our business/agency. I don't think finding
>>>
>> justification for
>>
>>> closed software means we should place a label on software
>>>
>> and treat it
>>
>>> any differently from any other software. Closed software should be
>>> accessible and follow the same technical standards as any other
>>> software.
>>>
>>> Regards,
>>>
>>>
>>> Norman B. Robinson
>>> Section 508 Coordinator
>>> IT Governance, US Postal Service
>>> phone: 202.268.8246
>>>
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
>>> Vanderheiden
>>> Sent: Tuesday, December 19, 2006 12:45 PM
>>> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
>>> Web/Software Subcommittee'
>>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
>>> Subject: Re: [teitac-closed] "closed software"
>>>
>>>
>>> Some possible examples of closed software.
>>>
>>> Maybe some things like: (numbered only to facilitate discussion)
>>>
>>> 1 - Software that for security reasons does not allow anything to
>>> access what it has on screen and which reads keyboard registers
>>> directly to avoid tampering or 'remote' typing.
>>>
>>> 2 - Software designed to run on a product without and operating
>>> system.
>>>
>>> 3 - Software that has no API for AT - but instead has built in
>>> accessibility since there is no AT vendor who will work with and
>>> support the unique capability of the software because the market is
>>> too small for AT vendors.
>>>
>>> 4 - Something like Randy pointed to (see just below). The
>>>
>> hardware is
>>
>>> not closed since new software can be loaded. But the
>>> platform/software is closed.
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 6:55 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 03 2007 7:25 PM
Subject: Re: "closedsoftware"

Hi David,

> the difference with word pad is tthat it does not act as an interface
> to the rest of windows.
>

I fear I wasn't clear in my WordPad reference. In other discussions,
we've said that the applications that come with an OS need to follow the
application accessibility rules. Thus, we don't treat WordPad the way
we would treat the disk drivers or network i/o subsystem. We treat it
as an application that just happens to come with the OS (no different
than MS-Office, an app that doesn't come with the OS).

My WordPad analogy is to AT - whether it comes with an OS or not, it is
AT; just as WordPad is an app, whether it comes with the OS or not.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> On Jan 3, 2007, at 3:07 PM, Peter Korn wrote:
>
> Hi Gregg,
>
> I don't understand this. Is it part of the definition of AT that it
> comes from a 3rd party, separate from the OS? Or can it be the same
> party as the OS, but just not with the OS (e.g. ScreenReader/2 for OS/
> 2)?
>
> Separately, today in the Web & Software SC call, Andi asked about non-AT
> voice recognition software (is it only AT if it is called "AT"?).
>
>
> I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and later),
> and Gnopernicus & GOK (bundled with Solaris 10), and GOK & Orca (bundled
> with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly the same way that
> we (now) say that WordPad is an application (even though it is bundled
> with Windows).
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>> I thought of that as I wrote it.
>>
>> Well, since it is built into the OS, the application that work with
>> it would
>> be directly accessible since they are accessible without needing
>> any AT.
>> Remember that any software with access built in would need to rely
>> on OS
>> functions (speech, sound, keyboard etc). this would also rely on the
>> voiceover functionality.
>>
>> Since they have an API - it would ALSO be compatible with any AT
>> that was
>> out there.
>>
>> Having an API only though - without AT support would not be
>> accessible (i.e.
>> usable with people who have disabilities) if there was no AT. That
>> is why
>> Apple built it into their system and have an API. They support AT
>> but are
>> not subject to AT availability - which was a problem for them - at
>> least for
>> screen readers.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>>> David Poehlman
>>> Sent: Wednesday, January 03, 2007 4:38 AM
>>> To: TEITAC Web/Software Subcommittee
>>> Cc: 'TEITAC self contained/closed products subcommittee';
>>> 'TEITAC General Interface Accessibility Subcommittee'
>>> Subject: Re: [teitac-general] [teitac-websoftware]
>>> [teitac-closed] "closed software"
>>>
>>> greg, am I to understand then that your #2 excludes the Mac
>>> which has its ownn AT?
>>>
>>> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>>>
>>> Hi Norman,
>>>
>>> I agree with your premise that there shouldn't be any closed
>>> software.
>>>
>>> But if there is software that is closed (not accessible to
>>> AT) for any reason (business, technical or security) then we
>>> do want to require that it
>>> is accessible - no? And I believe that there will be legitimate
>>> arguments
>>> for some places where the software will be closed - and/or
>>> that there will be no AT developed for or that can be used
>>> with the product.
>>>
>>> I'm not talking about desktop computers necessarily.
>>>
>>> What if we just said
>>>
>>> 1) that products need to be accessible either via available
>>> assistive technology or directly accessible.
>>>
>>> 2) that products that require productivity (e.g.
>>> workstations) need to be accessible to assistive technologies
>>> to allow matching of user abilities necessary to achieve high
>>> levels of productivity.
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>
>>>>
>>> Of Robinson,
>>>
>>>
>>>> Norman B - Washington, DC
>>>> Sent: Wednesday, December 27, 2006 2:54 PM
>>>> To: TEITAC self contained/closed products subcommittee; TEITAC
>>>> Web/Software Subcommittee
>>>> Cc: TEITAC General Interface Accessibility Subcommittee
>>>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>>>>
>>>> Since I earlier offered a different perspective on "closed
>>>>
>>>>
>>> software",
>>>
>>>
>>>> I thought I would respond to each item.
>>>>
>>>> 1. Security reasons: Security should be a part of a
>>>>
>>>>
>>> requirement in the
>>>
>>>
>>>> same way accessibility should be a part of the requirement for a
>>>> product. First, security options _CAN_ be accessible (e.g.,
>>>>
>>>>
>>> accessible
>>>
>>>
>>>> CAPTCHAs or accessible login screens). Second, where there is a
>>>> technical determination that no access to application programming
>>>> interfaces (APIs) that work with assistive technology is allowed,
>>>> there is a business justification. No matter what assistive
>>>>
>>>>
>>> technology
>>>
>>>
>>>> can do, if the system designed to block user interaction to
>>>>
>>>>
>>> only one
>>>
>>>
>>>> type of system interface for business reasons, that is an
>>>>
>>>>
>>> exception.
>>>
>>>
>>>> However, I'd be amiss if I didn't say see "First".
>>>>
>>>> 2. Besides semantics, and debating among friends, software
>>>>
>>>>
>>> can't run
>>>
>>>
>>>> without an operating system unless it, itself, IS the operating
>>>> system.
>>>>
>>>> 3. What is the point of making a classification of "CLOSED
>>>>
>>>>
>>> SOFTWARE"?
>>>
>>>
>>>> What does it mean to us in context of Section 508? Your
>>>>
>>>>
>>> example is one
>>>
>>>
>>>> of being accessible through design. I'd say the example
>>>>
>>>>
>>> doesn't help
>>>
>>>
>>>> the argument and problem we are trying to solve (if you'll please
>>>> forgive me). We are concerned when software doesn't work with
>>>> assistive technology and isn't designed to be accessible.
>>>>
>>>>
>>> I'd also say
>>>
>>>
>>>> I have the expectation that this software is generally only used in
>>>> conjunction with specialized hardware. Firefox web browser was
>>>> considered to be too small a market for certain AT vendors.
>>>>
>>>>
>>> What does
>>>
>>>
>>>> that mean? I think they have an API. I think this is complex
>>>> interaction of _accessibility interfaces_ dependent on the
>>>>
>>>>
>>> operating
>>>
>>>
>>>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
>>>> considerably. It is too easy to just think in context of
>>>>
>>>>
>>> one platform,
>>>
>>>
>>>> especially when embedded operating systems in phones are so
>>>>
>>>>
>>> plentiful
>>>
>>>
>>>> and experiencing these same issues. Sorry to ramble, I
>>>>
>>>>
>>> think I need to
>>>
>>>
>>>> discuss this some more.
>>>>
>>>> 4. Platform software issues are interesting. Is commercial
>>>> availability exemptions? Tying it to vendor product and 'official'
>>>> support is dangerous too; I'm sure my MS Windows vendor doesn't
>>>> support me running Linux on my corporate desktop, but the screen
>>>> reader and web browser works just fine for most of my
>>>>
>>>>
>>> needs. I think
>>>
>>>
>>>> that is close to the earlier iPod firmware upgrade. But who cares?
>>>> Even if a 3rd party or Apple made the software as an add-on to the
>>>> product it can be made accessible. The debate so far has focused on
>>>> the vendor not developing assistive technology. Third
>>>>
>>>>
>>> parties do and
>>>
>>>
>>>> you can make things accessible without assistive technology.
>>>>
>>>> Sorry to disagree, but the closed software approach doesn't
>>>>
>>>>
>>> work well
>>>
>>>
>>>> for Section 508 evaluation. I can't help but feel we're not
>>>>
>>>>
>>> asking the
>>>
>>>
>>>> right questions. DRM is bad for end-users, security typically
>>>> negatively impacts end-user experience, and accessibility
>>>>
>>>>
>>> is all about
>>>
>>>
>>>> the user!
>>>> This discussion is really useful for questioning vendors
>>>>
>>>>
>>> and how they
>>>
>>>
>>>> support our business/agency. I don't think finding
>>>>
>>>>
>>> justification for
>>>
>>>
>>>> closed software means we should place a label on software
>>>>
>>>>
>>> and treat it
>>>
>>>
>>>> any differently from any other software. Closed software should be
>>>> accessible and follow the same technical standards as any other
>>>> software.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Norman B. Robinson
>>>> Section 508 Coordinator
>>>> IT Governance, US Postal Service
>>>> phone: 202.268.8246
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
>>>> Vanderheiden
>>>> Sent: Tuesday, December 19, 2006 12:45 PM
>>>> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
>>>> Web/Software Subcommittee'
>>>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
>>>> Subject: Re: [teitac-closed] "closed software"
>>>>
>>>>
>>>> Some possible examples of closed software.
>>>>
>>>> Maybe some things like: (numbered only to facilitate discussion)
>>>>
>>>> 1 - Software that for security reasons does not allow anything to
>>>> access what it has on screen and which reads keyboard registers
>>>> directly to avoid tampering or 'remote' typing.
>>>>
>>>> 2 - Software designed to run on a product without and operating
>>>> system.
>>>>
>>>> 3 - Software that has no API for AT - but instead has built in
>>>> accessibility since there is no AT vendor who will work with and
>>>> support the unique capability of the software because the market is
>>>> too small for AT vendors.
>>>>
>>>> 4 - Something like Randy pointed to (see just below). The
>>>>
>>>>
>>> hardware is
>>>
>>>
>>>> not closed since new software can be loaded. But the
>>>> platform/software is closed.
>>>>
>>>> Gregg
>>>> -- ------------------------------
>>>> Gregg C Vanderheiden Ph.D.
>>>>

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 03 2007 7:30 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 7:35 PM
Subject: Re: "closedsoftware"

ah, agreed.

On Jan 3, 2007, at 9:15 PM, Peter Korn wrote:

Hi David,

> the difference with word pad is tthat it does not act as an interface
> to the rest of windows.
>

I fear I wasn't clear in my WordPad reference. In other discussions,
we've said that the applications that come with an OS need to follow the
application accessibility rules. Thus, we don't treat WordPad the way
we would treat the disk drivers or network i/o subsystem. We treat it
as an application that just happens to come with the OS (no different
than MS-Office, an app that doesn't come with the OS).

My WordPad analogy is to AT - whether it comes with an OS or not, it is
AT; just as WordPad is an app, whether it comes with the OS or not.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> On Jan 3, 2007, at 3:07 PM, Peter Korn wrote:
>
> Hi Gregg,
>
> I don't understand this. Is it part of the definition of AT that it
> comes from a 3rd party, separate from the OS? Or can it be the same
> party as the OS, but just not with the OS (e.g. ScreenReader/2 for OS/
> 2)?
>
> Separately, today in the Web & Software SC call, Andi asked about
> non-AT
> voice recognition software (is it only AT if it is called "AT"?).
>
>
> I suggest that Apple's VoiceOver (bundled with the OS X 10.4 and
> later),
> and Gnopernicus & GOK (bundled with Solaris 10), and GOK & Orca
> (bundled
> with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly the same way
> that
> we (now) say that WordPad is an application (even though it is bundled
> with Windows).
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>> I thought of that as I wrote it.
>>
>> Well, since it is built into the OS, the application that work with
>> it would
>> be directly accessible since they are accessible without needing
>> any AT.
>> Remember that any software with access built in would need to rely
>> on OS
>> functions (speech, sound, keyboard etc). this would also rely on the
>> voiceover functionality.
>>
>> Since they have an API - it would ALSO be compatible with any AT
>> that was
>> out there.
>>
>> Having an API only though - without AT support would not be
>> accessible (i.e.
>> usable with people who have disabilities) if there was no AT. That
>> is why
>> Apple built it into their system and have an API. They support AT
>> but are
>> not subject to AT availability - which was a problem for them - at
>> least for
>> screen readers.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>>> David Poehlman
>>> Sent: Wednesday, January 03, 2007 4:38 AM
>>> To: TEITAC Web/Software Subcommittee
>>> Cc: 'TEITAC self contained/closed products subcommittee';
>>> 'TEITAC General Interface Accessibility Subcommittee'
>>> Subject: Re: [teitac-general] [teitac-websoftware]
>>> [teitac-closed] "closed software"
>>>
>>> greg, am I to understand then that your #2 excludes the Mac
>>> which has its ownn AT?
>>>
>>> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>>>
>>> Hi Norman,
>>>
>>> I agree with your premise that there shouldn't be any closed
>>> software.
>>>
>>> But if there is software that is closed (not accessible to
>>> AT) for any reason (business, technical or security) then we
>>> do want to require that it
>>> is accessible - no? And I believe that there will be legitimate
>>> arguments
>>> for some places where the software will be closed - and/or
>>> that there will be no AT developed for or that can be used
>>> with the product.
>>>
>>> I'm not talking about desktop computers necessarily.
>>>
>>> What if we just said
>>>
>>> 1) that products need to be accessible either via available
>>> assistive technology or directly accessible.
>>>
>>> 2) that products that require productivity (e.g.
>>> workstations) need to be accessible to assistive technologies
>>> to allow matching of user abilities necessary to achieve high
>>> levels of productivity.
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>
>>>>
>>> Of Robinson,
>>>
>>>
>>>> Norman B - Washington, DC
>>>> Sent: Wednesday, December 27, 2006 2:54 PM
>>>> To: TEITAC self contained/closed products subcommittee; TEITAC
>>>> Web/Software Subcommittee
>>>> Cc: TEITAC General Interface Accessibility Subcommittee
>>>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
>>>>
>>>> Since I earlier offered a different perspective on "closed
>>>>
>>>>
>>> software",
>>>
>>>
>>>> I thought I would respond to each item.
>>>>
>>>> 1. Security reasons: Security should be a part of a
>>>>
>>>>
>>> requirement in the
>>>
>>>
>>>> same way accessibility should be a part of the requirement for a
>>>> product. First, security options _CAN_ be accessible (e.g.,
>>>>
>>>>
>>> accessible
>>>
>>>
>>>> CAPTCHAs or accessible login screens). Second, where there is a
>>>> technical determination that no access to application programming
>>>> interfaces (APIs) that work with assistive technology is allowed,
>>>> there is a business justification. No matter what assistive
>>>>
>>>>
>>> technology
>>>
>>>
>>>> can do, if the system designed to block user interaction to
>>>>
>>>>
>>> only one
>>>
>>>
>>>> type of system interface for business reasons, that is an
>>>>
>>>>
>>> exception.
>>>
>>>
>>>> However, I'd be amiss if I didn't say see "First".
>>>>
>>>> 2. Besides semantics, and debating among friends, software
>>>>
>>>>
>>> can't run
>>>
>>>
>>>> without an operating system unless it, itself, IS the operating
>>>> system.
>>>>
>>>> 3. What is the point of making a classification of "CLOSED
>>>>
>>>>
>>> SOFTWARE"?
>>>
>>>
>>>> What does it mean to us in context of Section 508? Your
>>>>
>>>>
>>> example is one
>>>
>>>
>>>> of being accessible through design. I'd say the example
>>>>
>>>>
>>> doesn't help
>>>
>>>
>>>> the argument and problem we are trying to solve (if you'll please
>>>> forgive me). We are concerned when software doesn't work with
>>>> assistive technology and isn't designed to be accessible.
>>>>
>>>>
>>> I'd also say
>>>
>>>
>>>> I have the expectation that this software is generally only used in
>>>> conjunction with specialized hardware. Firefox web browser was
>>>> considered to be too small a market for certain AT vendors.
>>>>
>>>>
>>> What does
>>>
>>>
>>>> that mean? I think they have an API. I think this is complex
>>>> interaction of _accessibility interfaces_ dependent on the
>>>>
>>>>
>>> operating
>>>
>>>
>>>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
>>>> considerably. It is too easy to just think in context of
>>>>
>>>>
>>> one platform,
>>>
>>>
>>>> especially when embedded operating systems in phones are so
>>>>
>>>>
>>> plentiful
>>>
>>>
>>>> and experiencing these same issues. Sorry to ramble, I
>>>>
>>>>
>>> think I need to
>>>
>>>
>>>> discuss this some more.
>>>>
>>>> 4. Platform software issues are interesting. Is commercial
>>>> availability exemptions? Tying it to vendor product and 'official'
>>>> support is dangerous too; I'm sure my MS Windows vendor doesn't
>>>> support me running Linux on my corporate desktop, but the screen
>>>> reader and web browser works just fine for most of my
>>>>
>>>>
>>> needs. I think
>>>
>>>
>>>> that is close to the earlier iPod firmware upgrade. But who cares?
>>>> Even if a 3rd party or Apple made the software as an add-on to the
>>>> product it can be made accessible. The debate so far has focused on
>>>> the vendor not developing assistive technology. Third
>>>>
>>>>
>>> parties do and
>>>
>>>
>>>> you can make things accessible without assistive technology.
>>>>
>>>> Sorry to disagree, but the closed software approach doesn't
>>>>
>>>>
>>> work well
>>>
>>>
>>>> for Section 508 evaluation. I can't help but feel we're not
>>>>
>>>>
>>> asking the
>>>
>>>
>>>> right questions. DRM is bad for end-users, security typically
>>>> negatively impacts end-user experience, and accessibility
>>>>
>>>>
>>> is all about
>>>
>>>
>>>> the user!
>>>> This discussion is really useful for questioning vendors
>>>>
>>>>
>>> and how they
>>>
>>>
>>>> support our business/agency. I don't think finding
>>>>
>>>>
>>> justification for
>>>
>>>
>>>> closed software means we should place a label on software
>>>>
>>>>
>>> and treat it
>>>
>>>
>>>> any differently from any other software. Closed software should be
>>>> accessible and follow the same technical standards as any other
>>>> software.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Norman B. Robinson
>>>> Section 508 Coordinator
>>>> IT Governance, US Postal Service
>>>> phone: 202.268.8246
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
>>>> Vanderheiden
>>>> Sent: Tuesday, December 19, 2006 12:45 PM
>>>> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
>>>> Web/Software Subcommittee'
>>>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
>>>> Subject: Re: [teitac-closed] "closed software"
>>>>
>>>>
>>>> Some possible examples of closed software.
>>>>
>>>> Maybe some things like: (numbered only to facilitate discussion)
>>>>
>>>> 1 - Software that for security reasons does not allow anything to
>>>> access what it has on screen and which reads keyboard registers
>>>> directly to avoid tampering or 'remote' typing.
>>>>
>>>> 2 - Software designed to run on a product without and operating
>>>> system.
>>>>
>>>> 3 - Software that has no API for AT - but instead has built in
>>>> accessibility since there is no AT vendor who will work with and
>>>> support the unique capability of the software because the market is
>>>> too small for AT vendors.
>>>>
>>>> 4 - Something like Randy pointed to (see just below). The
>>>>
>>>>
>>> hardware is
>>>
>>>
>>>> not closed since new software can be loaded. But the
>>>> platform/software is closed.
>>>>
>>>> Gregg
>>>> -- ------------------------------
>>>> Gregg C Vanderheiden Ph.D.
>>>>

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 7:50 PM
Subject: Re: "closedsoftware"

I wonder if there is a distinction between at and accessible it?
Should we not be moving toward accessible it? If I install tiger I
get VoiceOver and all the otheer accessibility feeatures. This seems
to me like accessible IT.

On Jan 3, 2007, at 9:45 AM, Andrew Kirkpatrick wrote:

David,
The Mac OS has an accessibility API that is capable of supporting
assistive technologies - it just happens that Apple made their own, but
an outside company could develop a screen reader or other AT for that
OS.
AWK

David wrote:
greg, am I to understand then that your #2 excludes the Mac which has
its ownn AT?

Greg wrote:
2) that products that require productivity (e.g. workstations) need to
be accessible to assistive technologies to allow matching of user
abilities necessary to achieve high levels of productivity.

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 8:00 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Wed, Jan 03 2007 8:05 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: Andi Snow-Weaver
Date: Wed, Jan 10 2007 7:00 AM
Subject: Re: "closedsoftware"

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

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 10 2007 1:00 PM
Subject: Re: "closedsoftware"

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

Previous message | Next message

From: Peter Korn
Date: Wed, Jan 10 2007 1:15 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Sat, Jan 20 2007 4:50 AM
Subject: Re: "closedsoftware"

almost is only good in horse shoes.

On Jan 10, 2007, at 8:58 AM, Andi Snow-Weaver wrote:

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

Previous message | Next message

From: Gregg Vanderheiden
Date: Sat, Jan 20 2007 10:55 PM
Subject: Re: "closedsoftware"

This is in response to the question about what constitutes closed software -
and if there are examples beyond DRM and Operational security like voting.
Good questions.

1. I would think that any software that doesn't have a published API
that provides access to all information, and ability to control all function
from software, would be closed.

2. I think the question isn't "closed" or 'not closed'. I think we
should move away from the term closed, and instead use: "works with AT
that the users will have." That is simple, meaningful and understandable.
"closed" is none of those.

3. Other software closed by policy? Any software in a system that
doesn't allow installation of software except by administrator and the
administrator won't allow installation of user's AT. Libraries, college
computer labs etc. If the labs ALREADY have AT installed, then the
software on the systems is closed but accessible. But before we get all
bundled up about whether this is hardware or software accessibility that is
closed by policy - I would refer back to my point #2 above. I think we
should get away from the term "closed".

Also, as long as we are trying to label parts of a system (rather than the
whole system) as being open or closed or whatever - we can argue it both
ways. But components by themselves can be used nor assessed. They can
only be assessed in the context they are used. If software is a product
that will be run on an open PC then that is how it should be assessed. If
it will be run on a locked down kiosk then it would need access built in

My thoughts.

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

_____

From: Jim Tobias [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 19, 2007 6:54 AM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Web/Software Subcommittee'
Subject: RE: [teitac-websoftware] [teitac-closed] "closed software"

I think we've already agreed to an important distinction between "closed for
reasons of technical or commercial feasibility" and "closed for policy
reasons". I can think of examples of software that are closed for policy
reasons:

1. Digital rights management (DRM), where some proprietary information
(usually music, video, etc., or the rights to use the software itself) is
safeguarded against unauthorized use. Is it necessary or useful to break
this category down further? For example, the *content* itself can be closed
by using encryption or a proprietary file format. Or the *player* acts as
gatekeeper, either using some file metadata or other technique to permit
access to the content. In either of these cases, I cannot see why the
federal government could not require openness, especially where the content
(in the employee training example Terry Weaver gave us) is already either
created or licensed by the government itself. Any examples?

2. Operational security, like voting systems, where concerns about the
integrity of the results (back end) have trumped flexibility in the
interface (front end) and somehow it was judged infeasible to keep them
separate. I'd like to hear from those who were involved in the Voluntary
Voting System Guidelines (VVSG) work, whether they think we should be guided
by VVSG.

http://www.eac.gov/vvsg_intro.htm

Are there other types of software closed by policy?

I cannot think of any software that is closed by technical or commercial
feasibility. I think we have a false analogy between hardware and software
here. While there are hardware products that lack any connectivity (e.g.
calculators) for reasons of technical/commercial feasibility, software is by
its nature more adaptable to interconnection, and not subject to the iron
laws of manufacturing costs. That is, in the first case it may not be
burdensome to add a few lines of code that place some data into a location
where it can be read by another software process. In the second case, once
that code has been written there may be no additional cost to install it in
every instance where it needs to run.

It seems to me that the serious efforts being made at an Accessibility API
are software openness is technically and commercially feasible. Can anyone
think of counterexamples relevant to the case of federal procurement?

Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias

_____

From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 19, 2007 2:07 AM
To: 'TEITAC Web/Software Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

I think the concept of 'closed" is a good one in that it allows yet another
degree of innovation and flexibility. I agree that it should be an
'attribute' rather than a type of product since it is crosscutting. And
of course if you are closed then you need to build access in. As to being
hardware only. that might or might not be true depending on how we define
things.

We have an amazing number of really tough questions to cover.

Perhaps we should start with a bunch of examples or scenarios to map out the
territory.

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, January 18, 2007 11:35 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Joe,

I don't think having the distinction of "closed hardware" helps us at
all. But I advocate reorganizing the standards themselves in this regard. I
think there might be a place for this discussion in the preamble, but not in
the Section 508 technical standards themselves.

I think the self contained, closed products section really addresses is
hardware requirements. So I suggest the inclusion of all hardware related
functional requirements from all the other sections be consolidated along
with the hardware requirements in 1194.25 and call it "physical design
requirements".

As for the accessibility requirements of the software running on any
hardware, no matter what the form factor, the existing software standards
(or web standards specific to web content) applies.

Regards,

Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lazzaro,
Joe (ITD)
Sent: Monday, January 15, 2007 11:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

This may be a little radical, but do so called closed hardware devices
really have a place anymore? With the rapidly decreasing prices of
off-the-shelf hardware like PDAs and phones that support real operating
systems, why is industry building closed devices? It seems to me that a lot
of our problems could be solved if devices were open and able to accept
software applications, and assistive technology solutions as well.

At the very least, we could reload such closed devices with the operating
system, desktop, applications, and assistive technology that we choose.

Joe

Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Monday, January 15, 2007 10:53 AM
To: 'TEITAC self contained/closed products subcommittee'
Cc: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Randy wrote:
The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with. I think you're accurate in drawing the analogy
between the iPod hardware and PC hardware. Loading Rock Box on an iPod is
analogous to purchasing a PC with Windows loaded, but then reformatting the
hard drive and loading Linux instead. Same PC - different operating
systems. So, in terms of definition, I think you would still have to
characterize the iPod's software as closed (but its hardware as open).

[JT] I'm not sure that what you're saying is technically accurate. Is it
impossible to retain iPod functionality and only change the user interface?
If you can still sync your iPod, search for a song, and have complete play
control, but instead of the original controls use a speech interface or a
scanning control with the same or external hardware, I'd say the iPod is
functioning more like a PC with an OS that has not been overridden, but
supplemented by an AT user interface.

More to the point, can't the feds *require* the latter: a base unit that
allows the loading (and unloading) of a more accessible user interface?
(This, of course, does not mean that someone has created such an interface
-- we still have the tricky issue of a mainstream product that meets the
standards but is only accessible if AT is used, and no such AT is
available.)

And over to an even stickier concept: what is the true purpose of the
procurement? Let's say that the feds are issuing iPods for training
purposes, exactly as suggested by Terry Weaver. It's access to that
training content that matters, right? Let's say the content is mp3. Any
accessible mobile device capable of playing mp3s should qualify. Shouldn't
the requirement be that the *content* is provided in an accessible format,
as long as there is a procurable accessible mobile player that can play that
format? What would happen if part of the procurement was the distribution
channel for the content: only distributed via iTunes?

This takes us into a concept related to the "value chain". It's another one
imported from the world of business analysis: "product ecosystem". That is,
where does a given product fit in the context of other products and wholly
other ways of achieving the same goal? They use the word "ecosystem"
because it matches certain concepts from biology: there are keystone
species, dominant species, competition, cooperation, evolution, niches....

To contrast "value chain" and "product ecosystem", consider the iPod value
chain for federal training. It includes the training content developer,
iTunes, computer hardware and software companies, iPod, retailers, end users
(and their supervisors and IT managers). The product ecosystem would have
to show all possible value chains (now shown as products rather than
companies) from the training content developer to the end users. Think of
all the ways the mp3 content could reach the user aside from the iPod chain:
CD, email attachment, broadcast, website download, website stream.... The
richness of ICT product ecosystems is stunning once you look at the *goals*
rather than the gadgets.

The upside of such a view is that it can be much more "efficient": rather
than requiring every product to include every accessibility feature, you
only need to guarantee a robust subset of chains (not just one) that offer
the full range of accessibility. The downsides are that:

1. you need to have really specific goals in mind

2. you need to guarantee the robustness of the chains

3. you need to monitor the market for rapid evolutionary changes (products
and product types entering and leaving)

Disability advocates may assume that such an approach is the same as the
rejected "product line" approach, which would have let companies create one
accessible product per product type, or that it is about accommodations, not
universal design. There are risks of both of those in a product ecosystem
approach, but they can be addressed.

Note that the tradeoff between the current "all products must be fully
accessible in and of themselves" regulatory approach and a goal-oriented
product ecosystem approach is that technical costs are traded for
information costs. That is, the myth of the current approach is that it's
feasible to put every accessibility feature in every product; the myth of
the product ecosystem approach is that it's feasible to find out the optimal
mix of products so that any given user's accessibility needs are addressed.
Perhaps this speaks to a hybrid approach, in which features that are "very
readily achievable" or "almost burdenless" are required to be universally
implemented, while others are considered within a goal-oriented framework.

***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com

Previous message | Next message

From: Peter Korn
Date: Mon, Jan 22 2007 12:15 PM
Subject: Re: "closedsoftware"

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

Previous message | Next message

From: Peter Korn
Date: Mon, Jan 22 2007 12:20 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Mon, Jan 22 2007 12:25 PM
Subject: Re: "closedsoftware"

Hi Peter.

Where did this questionn come from?
Is it appropriate for 508 to require mainstream IT to be compatible with
every AT product ever shipped for a given platform
My stand I fear is in the opposite direction, 508 should require
Mainstream IT to be accessiible but probably not ttill itteration 9
or 10.

On Jan 22, 2007, at 2:09 PM, Peter Korn wrote:

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

Previous message | Next message

From: David Poehlman
Date: Mon, Jan 22 2007 12:30 PM
Subject: Re: "closedsoftware"

Previous message | Next message

From: David Poehlman
Date: Thu, Feb 01 2007 7:10 AM
Subject: Re: "closedsoftware"

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?

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

Previous message | Next message

From: David Poehlman
Date: Thu, Feb 01 2007 7:15 AM
Subject: Re: "closedsoftware"

Previous message | Next message

From: Hoffman, Allen
Date: Thu, Feb 01 2007 11:00 AM
Subject: Re: "closedsoftware"

The challenge with this finding the middle ground is to identify when
possible who is the authority for which components under what
circumstances. If that can be done this can be definable. For example,
if an OS is required to provide an API that can be used by applications
and assistive technologies, or rely upon a 3rd party API, that meets
minimum requirements, then boundaries might be clear. In this case, the
OS would document what API(s) it supports for this use, which could be
more than one, and the AT would then document what API(s) it supports.
When determining compliance for an OS one would include API
support/provisioning as part of the picture, and would then also have
dependent items possibly. AT would be evaluated for the OS it is
dependent upon possibly.

This may be workable even in situations of 3rd party API(s).

the important factor for the evaluator then would be to understand "how"
to evaluate such information.

the important part for OS manufacturers would be document what, if any,
API(s) are supported for applications and AT use.

The important part for At vendors is to document what API(s) and OS(s)
they support.

AT should use available information when it is helpful. Os(s) and other
frameworks should have available mechanisms to communicate critical
information to AT. And when a combination of items is being evaluated,
those that use such mechanisms should be considered generally more
accessible over all than others--as in theory this is a more generalized
approach to providing accessibility to multiple AT(s), and applications
without customizing each one continuously.

There, that is a mouthful for sure.

Hopefully some of this is helpful to start spotlighting where lines may
be started for this discussion.

Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Thursday, February 01, 2007 12:29 AM
To: TEITAC Web/Software Subcommittee
Cc: 'TEITAC General Interface Accessibility Subcommittee'; 'TEITAC
Subpart A Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-general]
[teitac-closed]"closed software"

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

Previous message |

From: Robinson, Norman B - Washington, DC
Date: Thu, Feb 01 2007 12:55 PM
Subject: Re: "closedsoftware"

Allen Hoffman said "Hopefully some of this is helpful to start
spotlighting where lines may
be started for this discussion."

At issue is in defining an API, how does that impact the developers and
how does that increase the likelihood for accessibility? Certainly
program design comes into play. On that note, I thought a thread in
= EMAIL ADDRESS REMOVED = would be relevant and useful to
consider, so I've copied the entire post below my signature. Perhaps
someone reading this also subscribes to the blindprogramming list and
can further expand upon these ideas in context to this conversation.

Regards,

Norman B. Robinson

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sina
Bahram
Sent: Wednesday, January 31, 2007 11:59 AM
To: 'Steve Lee'
Cc: = EMAIL ADDRESS REMOVED = ; 'Peter';
= EMAIL ADDRESS REMOVED =
Subject: RE: Application design,was RE: Screen readers and chat or
instant messaging

Testing is actually facilitated by this, if the pattern is carried out
to
its fullest and done correctly.

My suggestion would be to use a common communication layer such a
software
buss to implement such an interface.

If all members/components of the buss are listening on this xml software
buss, then the ability of the application not to need hardcoded
components
is greatly increased.

Take care,
Sina

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve
Lee
Sent: Wednesday, January 31, 2007 6:28 AM
To: Sina Bahram
Cc: = EMAIL ADDRESS REMOVED = ; Peter;
= EMAIL ADDRESS REMOVED =
Subject: Re: Application design, was RE: Screen readers and chat or
instant
messaging

Hi Sina, that's interesting and has some overlap with my thoughts about
alternative input support allowing user selected gestures across various
devices (we calling this a capability palette).

As you describe it, it is the programs responsibility to support all
possible view/controlers but by using the current model of external AT
accessing via a11y API the user can choose, selecting the AT they want
to
use on all their programs independent of applications design decisions

Where AT uses an a11y API the assumption is that you go through the
UI/view/controller to the model and that obvious works reasonably well.
For
alt input we'd really like a standard way to allow AT to get at the
actions
independent of the application's particular UI bindings.

Unfortunately we can't easily standardise as that would require
developers
to use new design patterns and they will usually just design for the
common
OS supported input devices (mouse & keyboard) or add specific support
for
other devices (joystick, speech).

If we could assume that every action has a keyboard shortcut then that
could
be the action ID for the AT to use but that's not ideal. That's a big
if.

I've seen similar patterns to those you describe defined to allow
testing of
business objects without going through the UI which can be fragile
(change
often and break the tests). However you still need to test the UI.

--
Steve Lee
www.oatsoft.org
www.schoolforge.org.uk
www.fullmeasure.co.uk

On 1/31/07, Sina Bahram < = EMAIL ADDRESS REMOVED = > wrote:
I have copied the blind programming list on this single response, just
because I think this is a topic that comes up a lot, and I thought they
might enjoy the discussion.

Well, speaking from the pro abstraction, pro generic, and pro design
camp, my thoughts are below.

I think that an interface is nothing more than a methodology of
accessing the heart of what we are calling an application. Several
design patterns actually go along with this concept; for example, a
model view controller design splits off the application into a model
which contains the business logic of the application, a view which is
responsible for controllingwhat, how, and in what way the user receives
information from the model, and a controller which is responsible for
interacting with the model and instructing, requesting, or in any other
way facilitating the request for an action to take place which may or
may not be reflected in the view.

There are other designs which integrate the view and the controller,
because sometimes this is simply easier. For example, it is quite easy
and convenient to store the methods of accessing a menu along with the
menu, but now if you want to use the option in that menu with a speech
activated command, single switch device, or via some programmatic means:
you will have to get around the fact that it is hardcoded as a menu
item. The alternative method of designing something along the lines of
separation of the model and the view, as well as the controller, would
be to design the application in such a way that you have actions in the
model which can be acted upon, act on their own, or in any other way
affect the internal representation of the program's state. You then have
a model which wraps these actions and exposes these behaviors,
functionality, and information to the view for display and the
controller for interaction. In this way, multiple views can be written
with absolutely 0% change of the model.

Let's take this back to the menu item that was hard coded before. Now
what would have to happen is that a new speech input based view could
simply be
placed into the application, which simply called the same feature in
the model that the menu item did in the visual view.

A new view sounds complicated, but it could be as easy as a single
method that had to be written, a new class, or as complex as a new
package being added to the application.

So, to wrap up. I think that abstraction is going to be your friend if
you are going to struggle with issues of multiple interfaces. Simply
abstract out the actions into a group which can be wrapped by a model,
provide multiple forms of accessing this model via various controllers,
and then provide multiple views if needed.

So for example, you can have the same model representing that action
which that menu item pointed to, but now you could have a visual UI that
displayed
the menu, an audio based UI which read it out loud, a speech input
controller that worked on spoken commands, and a controller that is
keyboard/mouse driven.

We now have provided the user with four fundamental ways to use the
application, and we haven't touched a single line of model code. They
can either have a visual UI with keyboard/mouse control, a visual UI
with speech input control, an audio based UI with keyboard/mouse
control, or an audio based UI with speech input control.

Furthermore, they can have combinations of the above, so for example,
they could have a visual UI and audio based UI with both keyboard/mouse
and
speech input control.

None of this has affected the model's code at all.

If you actually do the math on that, by abstracting it out this way,
you have provided four factorial ways of using the application which
amounts to
24 possible methodologies of access, when we only started with two,
because we were hard coding.

I hope this made sense? I don't usually type so much on this list, but
design and abstraction are really close to my heart, and I believe that
is the way we are going to enter the new generation of computing.

Take care,
Sina

-----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Peter
> Sent: Tuesday, January 30, 2007 6:35 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: Screen readers and chat or instant messaging
>
> Good question, I'm still trying to work this out as I work on
developing
> another accessible chat program. I've thought about this post for a
few
days
> though.
>
> My first instinct was to lean on simplicity and in the case of the
aria
> role=*, keep it also as simple as possible. However, I'm not sure
about
that
> anymore.
>
> I'm currently struggling a bit with context issues in my chat. For
example
> I'd like the chat program to aid users when they fall behind.
> My idea for this is currently a pause feature that allows a user to
travel
> up and down the paused chat thread. So for example, suppose a screen
reader
> user keys the pause button, at this point some basic information would
> helpful such as: number of lines behind in current chat, filter
options
> (e.g. budies), chat message summaries (e.g. first
> 2 words from each chat message), and so on. All of this could be
> accomplished (I think - still working on it :) on the server-side and
by
> only displaying the relevant information to the screen reader.
>
> The above would involve some hack-ish work on the chat log, traversing
up
> and down and gathering information creatively. Having chat events
(each
"new
> line of information is a new event, in time order"-Aaron) would make
me
jump
> for joy! I imagine at least that it would make traversing a log easier
and
> cleaner. Also, future unkown uses of Ajax, if this were implemented,
would
> probably creep up in ways we couldn't now predict. Think of HTML
tables -
a
> data table for layout, I doubt anyone back in the day predicted that.
>
>
> As an off--this-thread-topic.
>
> I'm kind of stuck on a theoretical question about a chat program.
> Which is "better":
> a) a chat program that includes all features/options: accessible/non/*
>
> -or-
>
> b) a chat program that has separate interfaces for different types of
> users: accessible/non/*
>
> This actually started out as an argument between colleague and I. On
one
> hand fewer options keeps things simple for the user and the chat can
> arguably be more customized to, for example, an assistive technology.
On
the
> other hand I would argue that a chat program that doesn't incorporate
the
> different features/options/interfaces well that either the code or the
UI
is
> flawed and should be re-designed.
>
> Which is "better"?
>
> -PeterT
>
>
> On Jan 26, 1:38 am, Aaron Leventhal < = EMAIL ADDRESS REMOVED = >
> wrote:
> > Question for all the screen reader users out there ...
> >
> > How should a screen reader behave in a chat application? Are there
any
> > special commands or changes in the way review mode works?
> >
> > Or is it just like anything else? One reviews the chat log like it's
a
> > document. That makes me wonder whether there's a quick command to
> > navigate to the end of the chat log, which is typically the most
> > recent message.
> >
> > - Aaron
>
>
>

WebAIM is an initiative of: